On 09/03/2009, at 1:44 PM, Jasper Bryant-Greene wrote:
> How is that different from normal IP routing? The other end always
> decides which way to send packets back to you, and in the event that
> your customer is multihomed, the return path might not even transit
> your AS.
I control my outbound and inbound routing. People only send packets
via routes I advertise and I can show a contractual relationship
between me and my upstream or peer, my upstream and theirs or their
peer and then to the far end etc.
With using 6to4 the downside is that whilst I may have my own gateway,
the FAR end could be using a 3rd party 6to4 gateway. This means that
the return packets traverse links for which I have no contractual
I guess in some way I'm agreeing with Joe that everyone SHOULD run
their own, especially if they offer up content over IPv6. (I wonder
if Google do with ipv6.google.com?).
Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc(a)internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
A client is complaining that a user at Xtra is not receiving email they sent.
I sent a test email and viewed the MX logs and found the following:
mx1.tnz.mail.yahoo.com[18.104.22.168] refused to talk to me: 421 Message from
(DELETED) temporarily deferred - 4.16.50. Please refer to
This is also appearing on other mail servers with other senders.
Is this something Xtra is doing across the board or is there another
The web link showing has no information corresponding to the status result.
-------- Original Message --------
Subject: [ipv6-wg] Youtube over IPv6!
Date: Fri, 29 Jan 2010 20:33:20 +0100
From: Martin Millnert <millnert(a)csbnet.se>
Hello fellow IPv6 admirers,
(I'm sending this here on behalf of Shane. :) )
As you might know already, Google has been so *tremendously* kind to, as
of ~22 hours ago, initiate the enabling of their Youtube site over IPv6.
It is currently available to participants in their Google over IPv6
program, http://www.google.com/intl/en/ipv6/ .
The www.youtube.com user interface so far does *not* have any AAAA
published, but the *much* more important (traffic wise) image and video
servers do. Use tcpdump to verify.
anticimex@hsa:~$ host s.ytimg.coms.ytimg.com is an alias for static.cache.l.google.com.
static.cache.l.google.com has address 22.214.171.124
static.cache.l.google.com has IPv6 address 2001:4860:4001:402::15
anticimex@hsa:~$ host v1.lscache1.c.youtube.comv1.lscache1.c.youtube.com is an alias for v1.lscache1.l.google.com.
v1.lscache1.l.google.com has address 126.96.36.199
v1.lscache1.l.google.com has IPv6 address 2001:4860:4001:402::10
The time when it began is clearly visible in our own IPv6 graphs,
and you can see similar correlated data at for example
To figure out all the mappings they give you, if you want to trace etc,
something similar to: "for i in `seq 1 24 `; do for y in `seq 1 8 `; do
host v$i.lscache$y.c.youtube.com ; done ; done | grep 'IPv6 address' |
cut -d' ' -f 1,5 | sort -uk2" could be used - at least from where I sit.
Adjust for correctness.
I'm sure that as this matures and bugs are wiped out, there will no
longer be any need for the Google over IPv6 program and everybody will
be able to access this. Until then, join! :)
I bow to the Google IPv6 team, their netops and everybody there that is
working so hard to give the Internet true CONTENT on IPv6. Yippie!
>From 48514, much of love! Thank you guys (and gals)!
Martin Millnert <millnert(a)csbnet.se>
Thanks to CommsDay for the information.... We're just here at NZNOG and it would be of massive interest to everyone in the room.
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve(a)eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
NOC, NOC, who's there?
Australasia's telecommunications daily since 1994 incorporating The Line of New Zealand
Telecom NZ submits two bids, Vector, TeamTalk also in the race for NZ FTTH rollout funds
Bids close this afternoon for the New Zealand Government's NZ$1.5 billion fibre-to-the-home project. The government is looking for partners to invest and participate in up to 33 local fibre companies. Although the submissions are confidential, many potential participants have gone public with at least some information.
Telecom NZ submitted two proposals, one compliant and one non-compliant, as well as expressing an interest in coming to an accommodation with the government even if these plans are rejected. The company said a national approach is required to deliver "a consistently engineered and interconnected network". It also talked in terms of not duplicating what has already been built.
In a media statement CEO Paul Reynolds said; "In addition to the two proposals Telecom is submitting, Telecom is open to discussing other alternative proposals which achieve the government's objective, avoid unnecessary waste and align the incentives and investment plans of both the government and Telecom".
The published terms of the project expressly forbid a telco from participating if it has both retail and wholesale operations - effectively ruling out Telecom NZ while it retains control of its Chorus access network division. This has triggered speculation the company is considering divesting itself of the business - even though there have been repeated assurances this is not in prospect.
One of the two proposals involves building on the company's existing fibre-to-the-node as a springboard for fibre-to-the-home. Telecom's two bids are a function of the submission process where bidders offering a non-compliant bid must also submit a compliant bid and explain why non-compliance is preferable.
In its bid, Auckland-based lines company Vector has gone for speed promising to deliver ultra-fast broadband to the premises across the city in seven years - beating the government's target by three years. The submission says its compliant bid means fibre will pass 133,000 premises within two years and connect more than half of all businesses within four years. Like Telecom NZ, Vector's public statements make much of its ability to "leverage existing assets".
Vector is a member of The New Zealand Regional Fibre Group (NZRFG) which says a number of other members have submitted proposals. The NZRFG said it is "Developing a proposal which could provide a dramatic step-change through the creation of an open access, national layer 2 (or lit) fibre network".
NZRFG members have submitted consortium bids for the Waikato and the Otago and Southland regions.
Northpower submitted a bid for the Northland region. David Ware of TeamTalk confirmed to CommsDay his company's bid for the Wellington region. He said his company was among the first in the world to do "metro dark fibre stuff" and has 10 to 15 years experience along with the resources and relationships to handle the job. - Bill Bennett
More details in Monday's CommsDay
I hand-waved the question about DNSSEC and DNS64 in my talk
The full answer is in
Extracting the main bits:
1. If CD is not set and DO is not set, vDNS64 SHOULD perform
validation and do synthesis as needed.
2. If CD is not set and DO is set, then vDNS64 SHOULD perform
validation. Whenever vDNS64 performs validation, it MUST
validate the negative answer for AAAA queries before proceeding
to query for A records for the same name, in order to be sure
that there is not a legitimate AAAA record on the Internet.
Failing to observe this step would allow an attacker to use DNS64
as a mechanism to circumvent DNSSEC. If the negative response
validates, and the response to the A query validates, then the
vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
answer to the client.
3. If the CD bit is set and DO is set, then vDNS64 MAY perform
validation, but MUST NOT perform synthesis. It MUST hand the
data back to the query initiator, just like a regular recursive
resolver, and depend on the client to do the validation and the
The disadvantage to this approach is that an end point that is
translation-oblivious but security-aware and validating will not
be able to use the DNS64 functionality. In this case, the end
point will not have the desired benefit of NAT64. In effect,
this strategy means that any end point that wishes to do
validation in a NAT64 context must be upgraded to be translation-
aware as well.
Existing DNSSEC validators (i.e. that are unaware of DNS64) will
reject all the data that comes from the DNS64 as having been tampered
with. If it is necessary to have validation behind the DNS64, then
the validator must know how to perform the DNS64 function itself.
Alternatively, the validating host may establish a trusted connection
with the DNS64, and allow the DNS64 to do all validation on its