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