Subject: Re: [v6ops] Routers forwarding packet with link local source

From: james woodyatt <[email-masked]>
Date: Fri, 02 Dec 2011 10:49:32 -0800

On Nov 24, 2011, at 14:11 , Brian E Carpenter wrote:
> 
> And just maybe, that is preferable to never receiving
> the ICMPv6 reply at all. This seems to be a genuine hole in
> our specs.

I see no problem in our specs.  This is just an example of broken router implementation.

If a packet arrives at my host with a link-local source address, then I had better be able to reliably assert that it originated from a host addressable in the link-local scope of the interface where it was received.  When I reply to that address, I expect neighbor discovery and neighbor unreachability detection to apply to the link-local scope destination I will be using.

If the host in question is actually nine hops away and the link-local address scope doesn't apply to any of my interfaces, then those routers are stepping on my link-local addressing realm, and I WANT THEM TO STOP DOING THAT.  This behavior is not allowed by our specs for very good reason.

--
j h woodyatt <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Dec 2011 10:10:52 +1300

> I see no problem in our specs.  This is just an example of broken router implementation.

The choice is between not getting an ICMPv6 echo reply at all or getting one
with an invalid source address.

> If a packet arrives at my host with a link-local source address, then I had better be able to reliably assert that it originated from a host addressable in the link-local scope of the interface whe…

This would only really matter if you were in the habit of replying to echo replies.

> If the host in question is actually nine hops away and the link-local address scope doesn't apply to any of my interfaces, then those routers are stepping on my link-local addressing realm, and I W…

In every case except ICMP echo reply, I agree.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Fri, 02 Dec 2011 23:13:31 +0100

In your letter dated Sat, 03 Dec 2011 10:10:52 +1300 you wrote:
>> If the host in question is actually nine hops away and the link-local addres
>s scope doesn't apply to any of my interfaces, then those routers are stepping
> on my link-local addressing realm, and I WANT THEM TO STOP DOING THAT.  This 
>behavior is not allowed by our specs for very good reason.
>

The only type I would want to receive is Packet Too Big. But for consistency
reason I'd say, just keep the current rules and drop all such packets.
It just violates ingress filtering if my routers would forward those packets
to any of my LANs.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Dec 2011 11:20:20 +1300

On 2011-12-03 11:13, Philip Homburg wrote:
> The only type I would want to receive is Packet Too Big. 

I wonder if you've just identified another reason for PMTUD
failures? A router that (correctly) drops PTB with a link local
source address would break PMTUD.

> But for consistency

If we go that way, there also needs to be a Router Requirement that
every router MUST have at least one GUA for use as the source address
in ICMPv6 messages.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Fri, 02 Dec 2011 23:37:37 +0100

>source address would break PMTUD.

Yes. Though there are also routers that are broken wrt Packet Too Big messages
but send fine TTL execeed messages. I have to figure out what the vendor
is.

>every router MUST have at least one GUA for use as the source address

I think that's the best thing to do. In theory it should only be required if
the router connects link with different MTUs.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Dec 2011 14:47:30 -0800

> the router connects link with different MTUs.

IMHO, I believe we will be seeing more and more of that
as MTU diversity continues to proliferate.

Fred

---

From: james woodyatt <[email-masked]>
Date: Fri, 02 Dec 2011 15:44:42 -0800

On Dec 2, 2011, at 14:20 , Brian E Carpenter wrote:
> 
> If we go that way, there also needs to be a Router Requirement that every router MUST have at least one GUA for use as the source address in ICMPv6 messages.

ULA will work as so long as the ICMPv6 message won't transit the DFZ.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Dec 2011 17:43:21 -0800

On Fri, Dec 2, 2011 at 14:20, Brian E Carpenter <[email-masked]
> wrote:

> every router MUST have at least one GUA for use as the source address

I don't think you can mandate configuration issues in node requirements
docs. A conforming router is still a conforming router even if nobody
configures a global unicast address on it.

---

From: Gert Doering <[email-masked]>
Date: Sat, 3 Dec 2011 11:43:45 +0100

Hi,

> configures a global unicast address on it.

If the router is not able to send required ICMPv6 error messages, it's
not a conforming router.

And of course the vendors *could* enforce this - like in "ipv6 forwarding
is not operational unless a GUA is configured on an interface (in the 
same routing context)".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Philip Homburg <[email-masked]>
Date: Sat, 03 Dec 2011 13:52:28 +0100

>is not operational unless a GUA is configured on an interface (in the 

Yes, I was thinking the same thing.

---

From: Mohacsi Janos <[email-masked]>
Date: Sun, 4 Dec 2011 17:00:36 +0100 (CET)

> is not operational unless a GUA is configured on an interface (in the

I don't think this is a good idea. Several IPv6 networks are relying on 
OSPFv3 with link-local addresses on interfaces only.
- Generating ICMPv6 error with different source address scope is a bug
- Selecting GUA randonly for global desitani address is cosmetical problem
- It must be configurable to source address if it is unnumbered....

Best Regards,

 		Janos Mohacsi

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Sun, 4 Dec 2011 18:32:20 +0100

Hi,

> OSPFv3 with link-local addresses on interfaces only.

This is OK, and not a problem - but it implies that when sourcing an
ICMPv6 error destined to a GUA, it MUST use a GUA that is "borrowed"
from another interface.  Sourcing from link-local is plain wrong.

> - Generating ICMPv6 error with different source address scope is a bug

I'm not exactly sure I parse this right - "different source address scope"
compared to what?  To the GUA destination address (in which case I agree)
or to the link-local address (in which case I disagree).

> - It must be configurable to source address if it is unnumbered....

The problem is not "using a random GUA address" - the problem is "if the
router has no single GUA address, it can't use a GUA address as source
in this case".  And in this case it would be violating router requirements,
and shouldn't be forwarding IPv6 packets in the first place.

Gert Doering
        -- NetMaster

---

From: Mohacsi Janos <[email-masked]>
Date: Sun, 4 Dec 2011 19:01:56 +0100 (CET)

> from another interface.  Sourcing from link-local is plain wrong.

Probably you statement can be misunderstood.
I understood you statement "ipv6 forwarding
is not operational unless a GUA is configured on an interface" the 
following way:
ipv6 forwarding is not operational on an interface if no GUA  is 
configured on this particular interface.

I recommend rephrase it to:

"ipv6 forwarding is not operational if no GUA is configured on any 
interface"

This may be true, however MPLS forwarding might happen. See later.

> or to the link-local address (in which case I disagree).

Source and destination address scope must be the same.

> and shouldn't be forwarding IPv6 packets in the first place.

Probably MPLS gurus would not accept that. Many big MPLS network does not 
cope with IPv6 inside their core network. The core network (P routers) are 
forwarding according to MPLS labels. Edge routers (PE) is dealing with 
IPv4 and IPv6 to fulfill user requirements. You can see some hops inside 
MPLS core sometimes, sometimes not:
See:
http://www.learnios.com/viewtopic.php?f=5&t=34596

Best Regards,
 		Janos Mohacsi

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Dec 2011 09:16:30 +1300

Hi,

On 2011-12-05 07:01, Mohacsi Janos wrote:
> Probably MPLS gurus would not accept that. Many big MPLS network does
> not cope with IPv6 inside their core network. The core network (P
> routers) are forwarding according to MPLS labels. Edge routers (PE) is
> dealing with IPv4 and IPv6 to fulfill user requirements. You can see
> some hops inside MPLS core sometimes, sometimes not:
> See:

All that doesn't matter. If a router generates a PTB it is essential that
it has a valid global source address, so that conforming routers will
forward it. No excuses. Otherwise PMTUD is broken and that is not OK.

Traceroute being broken is annoying; PTMUD being broken is unacceptable.

A BCP on making PMTUD work for v6 is probably needed.

   Brian

---

From: Gert Doering <[email-masked]>
Date: Sun, 4 Dec 2011 22:30:26 +0100

Hi,

> configured on this particular interface.

Ah.  Indeed, that can be misleading.

> "ipv6 forwarding is not operational if no GUA is configured on any 

This is what I had in mind.  "... any interface in the same routing
context", to take L3 VPNs into account.

> Source and destination address scope must be the same.

Agree.

> http://www.learnios.com/viewtopic.php?f=5&t=34596

Well, I don't think that 6PE over an IPv6-less core network is a 
*particularily* good idea...  but that's a different discussion to be
held on a differnet day.

But indeed, if you build an MPLS network, have no IPv6 at all on your
P routers, and need to send back ICMPv6 error messages - then you have
a problem.  Those routers might not even have *link-local*s to source
their packets from. 

So I'd rather focus on fixing edge cases of non-broken networks...

Gert Doering
        -- NetMaster

---

From: Mohacsi Janos <[email-masked]>
Date: Sun, 4 Dec 2011 23:11:30 +0100 (CET)

> A BCP on making PMTUD work for v6 is probably needed.

Agreed. RFC 4890 also stating importance of proper ICMPv6 treatment.
However I am curious, if in MPLS core how often changing MTU internally. 
Or contrary relying only ingress and egress PE router to generate PTB.

Best Regards,
 		Janos Mohacsi