[142572] in North American Network Operators' Group
Re: How long is reasonable to fix a routing issue in IPv6?
daemon@ATHENA.MIT.EDU (Jared Mauch)
Thu Jul 7 09:22:18 2011
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <20110707061426.4A96F1195F60@drugs.dv.isc.org>
Date: Thu, 7 Jul 2011 09:20:07 -0400
To: Mark Andrews <marka@isc.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 7, 2011, at 2:14 AM, Mark Andrews wrote:
>> 3) If end-to-end connectivity works,=3D20
>>=20
>> Workarounds:
>>=20
>> the IPv4 only P/PE device should have some sort of IPv6 address =
placed =3D
>> on transit interfaces to allow TTL expired to be sourced from =
something =3D
>> capable (this IP doesn't need to be able to be reached/routed to that =
=3D
>> interface, just exist).
>>=20
>> I spent a lot of time looking at a similar problem and it ended up =
being =3D
>> a combination of #1 & #2 above. You will see this problem across The =
=3D
>> AT&T and Cogent networks in my experience.
>=20
> 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)=
