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

Thu Jul 7 23:03:28 UTC 2011

In message <4E15DFD7.3090802 at he.net>, Mike Leber writes:
> 
> 
> 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 i
> s true that if an MPLS-LSR/P device does not understand the IPv6 frame you wil
> l 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 p
> ackets? (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-a
> ddress 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, obscu
> ring 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 drop
> ping 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.

Thanks.

I wasn't trying to complain about HE's support, which has always
been good. I was trying to point out the not having working time
exceeded messages makes everybody's job harder.  That it is time
to take IPv6 seriously and part of doing that means making sure
that error reporting works.

Mark

> > 	- Jared
> >
> > (BTW, 2914 does do loose-rpf on inet6 to drop unrouted space on Juniper devi
> ces)
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org