How long is reasonable to fix a routing issue in IPv6?
Jared Mauch
jared at puck.nether.net
Thu Jul 7 13:20:07 UTC 2011
On Jul 7, 2011, at 2:14 AM, Mark Andrews wrote:
>> 3) If end-to-end connectivity works,=20
>>
>> Workarounds:
>>
>> the IPv4 only P/PE device should have some sort of IPv6 address placed =
>> on transit interfaces to allow TTL expired to be sourced from something =
>> capable (this IP doesn't need to be able to be reached/routed to that =
>> interface, just exist).
>>
>> I spent a lot of time looking at a similar problem and it ended up being =
>> a combination of #1 & #2 above. You will see this problem across The =
>> AT&T and Cogent networks in my experience.
>
> The path is going through AT&T.
Yes. AT&T and Cogent are aware of this. I think there may be an IETF draft out there that talks about this as well but don't have a pointer to it. It is true that if an MPLS-LSR/P device does not understand the IPv6 frame you will see no response for that TTL. It's only the P devices that do understand an IPv6 frame, but decide to put a mapped-v4 address in the ttl expired message.
The real questions are:
1) Is hurricane electric doing loose-rpf for ipv6/inet6 and dropping these packets? (and if they are, are you requesting they make this change?)
2) is a mapped-v4 address a valid *source* address on the wire even if it's not a valid dest?
3) should operators of IPv6 capable equipment be running them in an MPLS-LSR/P role be assigning an IPv6 address on interfaces to provide a valid source-address even if they are not reachable in return? Should the vendor provide a knob to generate the ttl expiry messages from some other source address, obscuring the interface IPs involved (such as a loopback)?
Mark, it may also be valuable to see testing from a server at ISC that doesn't transit HE to reach the ATT network. While you still can't see who is dropping your packets, you may find someone who doesn't have loose-rpf enabled and observe some of the other behaviors noted.
- Jared
(BTW, 2914 does do loose-rpf on inet6 to drop unrouted space on Juniper devices)
More information about the NANOG
mailing list