How long is reasonable to fix a routing issue in IPv6?

Thu Jul 7 16:33:27 UTC 2011

On 7/7/11 6:20 AM, Jared Mauch wrote:
> 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?)

We aren't doing loose-rpf on ISC's transit session (for the reason you 
stated and others).

> 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.

The problem observed also happens for native IPv6 packets sent to 
2001:1890:1112:1::1e

We can confirm the packets leave our network and are handed off to the 
correct party.

We've sent emails regarding this to the other parties involved with no 
response so far.  I'll make sure people start getting phone calls.

Mike.

> 	- Jared
>
> (BTW, 2914 does do loose-rpf on inet6 to drop unrouted space on Juniper devices)