Subject: [v6ops] A good example of why we need to careful about ULAs

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 May 2013 15:41:02 +0900

News at 11:

1. ULAs leak.
2. People assign ULAs by hand.

Yes, both of these a violation of IETF guidance. I don't think that matters
much, though - while we can always claim that the implementer/operator is
"holding it wrong", we should be careful that what we design/standardize is
hard to misconfigure and possibly robust in the face of misconfiguration.
Subtle nuances like "these addresses are global scope, but not globally
routable" tend to get lost very easily.

Of course, in the case of ULAs, there's not much that can be done about the
design at this point, but we should make an effort to make it clear that
the potential for misconfiguration exists and provide clear guidance on how
not to misconfigure them.

Personally, I think that providing said guidance is much more useful and
important than enumerating scenarios that aren't widely, if at all,
implemented, and I hope that the authors
of draft-ietf-v6ops-ula-usage-recommendations will agree.

Cheers,
Lorenzo

---------- Forwarded message ----------
From: Jeroen Massar <[email-masked]>
Date: Thu, May 30, 2013 at 4:59 AM
Subject: Usage of fd00::/8 on the Interwebz - something with filters and
uRPF
To: [email-masked]

...
 4  2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1)  20.755 ms  20.763 ms
 20.784 ms
 5  fd00:3303::1 (fd00:3303::1)  22.010 ms  21.984 ms  21.986 ms
 6  2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1)  17.806 ms  17.889 ms
 17.842 ms
 7  2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1)  18.720 ms  18.593 ms
 18.617 ms
...

Hmmmm fd00::/8, that really should never ever be visible on the Internet,
being Unique *LOCAL* Addresses.
And it does not look like they applied the randomness bit for picking a
prefix either.
You would also almost think that a /28 is more than enough address space to
put a few router loopbacks in.

It is apparently time for people to start checking their filters again
because it seems that these packets leak into other ASNs too...

More generally, do recheck your network for BCP38 compliance, please do
apply it and require your peers to do the same!

Greets,
 Jeroen

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2013 01:11:07 -0700 (PDT)

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: "[email-masked] WG" <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Thursday, 30 May 2013 4:41 PM
>Subject: [v6ops] A good example of why we need to careful about ULAs
> 
>
>
>News at 11:
>
>
>1. ULAs leak.
>

In the early news, not really a new problem.

RFC1918 and 100.64/10 leak too, and what is worse, I've seen people intentionally expose RFC1918s to other networks - the largest carrier here in .au uses RFC1918 addresses for their wholesale ADSL L2TP LACs (from memory, at least 20 to 30, spread across multiple /16s within 172.16/12) and then expect their many wholesale ADSL customers' to just accept those addresses and make them work within their own networks, despite their own, quite legitimate internal use of 172.16/12 (fortunately VRFs/VPNs can be used to isolate that address space from your own). So we can't pretend that RFC1918s have been perfectly used, and therefore ULAs being less private than intended is going to be new problem and experience. At least properly formed ULAs are unlikely to conflict with other network's ones, even if the other network has used fd00::/8, and if the two interconnecting parties have both been lazy and used fd00::/8, they'll both be victims of theirs and the other
 party's laziness (which they'll be used to, since they've probably experienced it with RFC1918). They'll probably resort to NPTv6 to fix it, because that is what they're used to, rather than using IPv6's address aging mechanisms to renumber to a properly formed ULA. Good luck to them, as long as it doesn't effect the rest of us.

>Yes, both of these a violation of IETF guidance. I don't think that matters much, though - while we can always claim that the implementer/operator is "holding it wrong", we should be careful that what we design/standardize is hard to misconfigure and possibly robust in the face of misconfiguration. Subtle nuances like "these addresses are global scope, but not globally routable" tend to get lost very easily.
>

I think recommending against ULAs is just going to result in people stealing other address spaces for devices that don't need global reachability - like 2001:db8::/32, or unused global address space (as we saw with 1/8, 5/8 and other IPv4 prefixes).

I think global address space comes with and implies a default assumption of global reachability, and you'll therefore have to actively take measures to ensure they don't provide global reachability if you don't want it. Link-locals don't cut it because they're not routable. The need ULAs fulfils is the gap in between global space and link-locals, and the one which RFC1918 generally fulfils in IPv4, except that the likelyhood of address space collision is reduced.

>
>Of course, in the case of ULAs, there's not much that can be done about the design at this point, but we should make an effort to make it clear that the potential for misconfiguration exists and provide clear guidance on how not to misconfigure them.
>
>

>Personally, I think that providing said guidance is much more useful and important than enumerating scenarios that aren't widely, if at all, implemented, and I hope that the authors of draft-ietf-v6ops-ula-usage-recommendations will agree.
>

So is this draft aiming for BCP status and therefore should only reflect best common practice? If not, I think it is reasonable to present scenarios where ULAs could be useful. We've got a lot of experience with private address spaces from IPv4 (the Deprecating Site Local Addresses RFC3879 is also a pretty complete list of the problems with RFC1918 addresses), so the only real difference is scenarios where concurrent global and private address spaces could be useful. In some cases, they'll just be more capable versions of what we've already doing in IPv4 e.g. private addressed loopbacks on routers, global addresses on the links, in a ULA environment you would add ULAs to the links too, which could make troubleshooting and other OAM less dependent on the global address space.

Regards,
Mark.

>Subject: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
> 4  2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1)  20.755 ms  20.763 ms  20.784 ms
> 6  2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1)  17.806 ms  17.889 ms  17.842 ms
> 7  2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1)  18.720 ms  18.593 ms  18.617 ms
>...
>
>Hmmmm fd00::/8, that really should never ever be visible on the Internet, being Unique *LOCAL* Addresses.
>And it does not look like they applied the randomness bit for picking a prefix either.
>You would also almost think that a /28 is more than enough address space to put a few router loopbacks in.
>
>It is apparently time for people to start checking their filters again because it seems that these packets leak into other ASNs too...
>
>More generally, do recheck your network for BCP38 compliance, please do apply it and require your peers to do the same!
>
>Greets,
> Jeroen
>
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 May 2013 18:07:12 +0900

> In the early news, not really a new problem.

The part where an RFC asserts says that we can generate globally unique
addresses with no global coordination is a new problem. Yes, in theory it
works, but in practice it doesn't, because everyone ends up using fd00:: -
because that's the way it worked in IPv4, and ULA is just RFC1918 all over
again, right?

The key point here is that people are going to assume is that ULA is like
RFC1918 and we should carefully document all the ways in which it isn't.

So is this draft aiming for BCP status and therefore should only reflect
> best common practice?

I think documents coming out of v6ops should reflect scenarios where there
is operational experience. I don't think v6ops is the place to say "here's
what we could build". It's the place to say "here's what we've built;
here's what works, and here's what doesn't".

As an example: we've already discovered one of the use cases in this draft
(the "use ULA as a pref64") is not a use case after all, because it causes
devices to prefer IPv4 transition technologies like 464xlat over NAT64. We
didn't know this because nobody had actually tried to *operate a network*
in such a use case. I happened to catch that one because I wrote and tested
an implementation, but who knows if there are caveats in any of the others?

If as an operational group we publish guidance to operators that doesn't
work in the real world (like the pref64 case above), it will be
embarrassing for us and wasteful of operators' time. We should strive to do
better than that.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 May 2013 11:38:40 -0400

Sent from my iPad

> RFC1918 and 100.64/10 leak too, and what is worse, I've seen people intentionally expose RFC1918s to other networks - the largest carrier here in .au uses RFC1918 addresses for their wholesale ADSL…

Actually, as I understand it, part of the reason for making ULA different from RFC-1918 and wasting such a large amount of address space on said boondoggle was to address exactly the situation you describe and allow said telecom to have IPv6 addresses that didn't conflict with their wholesale customers. Thus, while the above scenario is problematic in RFC-1918 IPv4 land, it's supposed to be one of the intended uses of ULA as I understand it.

Of course, GUA avoids these issues altogether, but apparently that's not good enough for reasons passing understanding.

> party's laziness (which they'll be used to, since they've probably experienced it with RFC1918). They'll probably resort to NPTv6 to fix it, because that is what they're used to, rather than using…

Ah, but eventually, it will.

Owen

> I think recommending against ULAs is just going to result in people stealing other address spaces for devices that don't need global reachability - like 2001:db8::/32, or unused global address spac…

I don't think it was recommending against the use of RFC-1918 that led to the above hijackings.

> I think global address space comes with and implies a default assumption of global reachability, and you'll therefore have to actively take measures to ensure they don't provide global reachability…

99.99+% of RFC-1918 is to provide for GUA conservation through overloaded NAT.

That being not only unnecessary, but very undesirable in IPv6...

As to a "default assumption of global reachability", this is a very harmful and very incorrect assumption. IPv6 GUA provides for global uniqueness. It may or may not be globally routable and even if routed may or may not be reachable.

> So is this draft aiming for BCP status and therefore should only reflect best common practice? If not, I think it is reasonable to present scenarios where ULAs could be useful. We've got a lot of e…

You say that as if dependency on the global address space is a bad thing.

IMNSHO, dependency on non-global addresses is where things get unnecessarily complicated.

Owen

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2013 14:23:15 -0700 (PDT)

>To: Mark Smith <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, 30 May 2013 7:07 PM
>Subject: Re: [v6ops] A good example of why we need to careful about ULAs
> 
>
>
>On Thu, May 30, 2013 at 5:11 PM, Mark Smith <[email-masked]> wrote:
>The part where an RFC asserts says that we can generate globally unique addresses with no global coordination is a new problem. Yes, in theory it works, but in practice it doesn't, because everyone ends up using fd00:: - because that's the way it worked in IPv4, and ULA is just RFC1918 all over again, right?
>

I don't agree with trying to create a registry for the non-centrally assigned ULAs (because I think those people probably think they now own that prefix), however here is quite a list to show that a lot of people from a variety of organisations get that ULAs aren't set to fd00::/8

http://www.sixxs.net/tools/grh/ula/list/

>
>The key point here is that people are going to assume is that ULA is like RFC1918 and we should carefully document all the ways in which it isn't.
>

Agree with documenting it. Site-locals were "fd00::". The site-local deprecation RFC is pretty much the inverse of all the ways ULAs aren't site-locals and RFC1918s.

>
>So is this draft aiming for BCP status and therefore should only reflect best common practice?
>
>
>I think documents coming out of v6ops should reflect scenarios where there is operational experience. I don't think v6ops is the place to say "here's what we could build". It's the place to say "here's what we've built; here's what works, and here's what doesn't".
>
>

>As an example: we've already discovered one of the use cases in this draft (the "use ULA as a pref64") is not a use case after all, because it causes devices to prefer IPv4 transition technologies like 464xlat over NAT64. We didn't know this because nobody had actually tried to *operate a network* in such a use case. I happened to catch that one because I wrote and tested an implementation, but who knows if there are caveats in any of the others?
>
>
>If as an operational group we publish guidance to operators that doesn't work in the real world (like the pref64 case above), it will be embarrassing for us and wasteful of operators' time. We should strive to do better than that.
>
>

Ok. So then a follow up question is how to provide perhaps more tutorial oriented information? RFCs, quite reasonably, provide enough information to justify what is proposed, and usually one use case, but not all of them. That may not be enough information for more of a novice fully understand the problem that is being solved, the variety of opportunities to use it, and the pros and cons of the use of what is proposed in those scenarios. I haven't thought v6ops was just a place to document what has been done, but rather to document any topics related to operations, including advice and more information on how things invented here and in other IPv6 working groups could be used.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 May 2013 09:45:15 +1200

On 30/05/2013 20:11, Mark Smith wrote:
> RFC1918 and 100.64/10 leak too, 

In traceroutes, link-locals sometimes leak too.

All these are confusing and make the traceroute hard to interpret,
but they don't actually *matter*. What matters is if they leak in
actual traffic such as attempted TCP connections. Does that happen?

   Brian

>  and what is worse, I've seen people intentionally expose RFC1918s to other networks - the largest carrier here in .au uses RFC1918 addresses for their wholesale ADSL L2TP LACs (from memory, at least 20 to 30, spread across multiple /16s within 172.16/12) and then expect their many wholesale ADSL customers' to just accept those addresses and make them work within their own networks, despite their own, quite legitimate internal use of 172.16/12 (fortunately VRFs/VPNs can be used to isolate that address space from your own). So we can't pretend that RFC1918s have been perfectly used, and therefore ULAs being less private than intended is going to be new problem and experience. At least properly formed ULAs are unlikely to conflict with other network's ones, even if the other network has used fd00::/8, and if the two interconnecting parties have both been lazy and used fd00::/8, they'll both be victims of theirs and the other

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 30 May 2013 15:07:37 -0700

On 2013-05-30 14:45, Brian E Carpenter wrote:
[..]
> In traceroutes, link-locals sometimes leak too.

I have never come across that; except maybe when tracerouting to a
link-local, and then, that would only be one hop anyway.

If you know how to replicate it, I am very interested in a packet dump
or what is involved to cause it.

> actual traffic such as attempted TCP connections. Does that happen?

One should only see a link-local when:
 - the source packet is link-local
 - the destination host only has a link-local and replies (TTL or so)

But that should never cross more than one (1) hop as link-locals should
not be forwarded.

Greets,
 Jeroen

---

From: joel jaeggli <[email-masked]>
Date: Thu, 30 May 2013 15:08:34 -0700

> actual traffic such as attempted TCP connections. Does that happen?
there's leaking and then there's leaking...

if nobody accepts the route bi-directional leakage is hard... and even 
loose rpf checks will discard traffic from sources like that

real providers on the internet are still accepting 100.100.0.0/24 
<http://bgp.he.net/net/100.100.0.0/24>from as4847  so that's an example 
of the other kind.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 31 May 2013 09:54:42 +1000

In message <[email-masked]>, Mark S
mith writes:
> 
> >Cc: "[email-masked] WG" <[email-masked]>; "draft-ietf-v6ops-ula-usage-reco=
> [email-masked]" <draft-ietf-v6ops-ula-usage-recommendations@too=
> ls.ietf.org> =
> 
> > =
> >On Thu, May 30, 2013 at 5:11 PM, Mark Smith <[email-masked]> wr=
> ote:
> >The part where an RFC asserts says that we can generate globally unique ad=
> dresses with no global coordination is a new problem. Yes, in theory it wor=
> ks, but in practice it doesn't, because everyone ends up using fd00:: - bec=
> ause that's the way it worked in IPv4, and ULA is just RFC1918 all over aga=
> in, right?
> >
> 
> I don't agree with trying to create a registry for the non-centrally assign=
> ed ULAs (because I think those people probably think they now own that pref=
> ix), however here is quite a list to show that a lot of people from a varie=
> ty of organisations get that ULAs aren't set to fd00::/8

All locally assigned ULA are in fd00::/8.  I think you meant
fd00:0000:0000::/48.  Yes I deliberatly added the extra zeros make
it clearer.

The example that started this thread was not in fd00:0000:0000::/48.
They may not have configured their border routers to block traffic
to/from fc00::/7 and their router may not have appropriate source
address selection rules for the reply.  Both of those are correctable.

fd00:3303:0000::/48 may not *look* random but it may well be random.

> >The key point here is that people are going to assume is that ULA is like =
> Agree with documenting it. Site-locals were "fd00::". The site-local deprec=
> ation RFC is pretty much the inverse of all the ways ULAs aren't site-local=
> s and RFC1918s.
> 
> >
> >So is this draft aiming for BCP status and therefore should only reflect b=
> est common practice?
> >
> >
> >I think documents coming out of v6ops should reflect scenarios where there=
>  is operational experience. I don't think v6ops is the place to say "here's=
>  what we could build". It's the place to say "here's what we've built; here=
> 's what works, and here's what doesn't".
> >
> >
> 
> >As an example: we've already discovered one of the use cases in this draft=
>  (the "use ULA as a pref64") is not a use case after all, because it causes=
>  devices to prefer IPv4 transition technologies like 464xlat over NAT64. We=
>  didn't know this because nobody had actually tried to *operate a network* =
> in such a use case. I happened to catch that one because I wrote and tested=
> >If as an operational group we publish guidance to operators that doesn't w=
> ork in the real world (like the pref64 case above), it will be embarrassing=
>  for us and wasteful of operators' time. We should strive to do better than=
>  that.
> >
> >
> 
> Ok. So then a follow up question is how to provide perhaps more tutorial or=
> iented information? RFCs, quite reasonably, provide enough information to j=
> ustify what is=A0proposed, and usually one use case, but not all of them. T=
> hat may not be enough information for more of a novice fully understand the=
>  problem that is being solved, the variety of opportunities to use it, and =
> the pros and cons of the use of what is proposed in those scenarios. I have=
> n't thought v6ops was just a place to document what has been done, but rath=
> er to document any topics related to operations, including advice and more =
> information on how things invented here and in other IPv6 working groups co=
> uld be used.
> 
> Regards,
> Mark.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 May 2013 13:52:13 +1200

> or what is involved to cause it.

I understand it happens when the router in question has a next-hop
that is link-local and it has been set to use that address as the
default source address for ICMP replies, *and* there is no source address
filter along the path that blocks it.

This is not new; there's a thread starting at:
http://www.ietf.org/mail-archive/web/v6ops/current/msg11277.html

> But that should never cross more than one (1) hop as link-locals should

True, although in the specific case of traceroute you get a bit of useful
information from the illegal forwarding (whether it's link-local or ULA).

    Brian
> .

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 31 May 2013 02:05:56 +0000

> -----Original Message-----
> From: Mark Smith [mailto:[email-masked]]
> Sent: Thursday, May 30, 2013 4:11 PM
> To: Lorenzo Colitti; [email-masked] WG

> of draft-ietf-v6ops-ula-usage-recommendations will agree.
[Bing] I agree it would be helpful to provide some basic/general operational guidance, and we did plan to include some in the next version.
But as Mark commented in the following, the original intention of this draft is about use scenarios. Operational guidance is only a supplementary.
 
> So is this draft aiming for BCP status and therefore should only reflect best
> common practice? If not, I think it is reasonable to present scenarios where
> ULAs could be useful. 

>We've got a lot of experience with private address
> spaces from IPv4 (the Deprecating Site Local Addresses RFC3879 is also a
> pretty complete list of the problems with RFC1918 addresses), so the only
> real difference is scenarios where concurrent global and private address
> spaces could be useful. 
[Bing] It might not be the "only" difference, but surely it is the most obvious advance comparing to IPv4, and it was the most important motivation to write the draft.

>In some cases, they'll just be more capable versions
> of what we've already doing in IPv4 e.g. private addressed loopbacks on
> routers, global addresses on the links, in a ULA environment you would add
> ULAs to the links too, which could make troubleshooting and other OAM less
> dependent on the global address space.
[Bing] Agreed. I think that would be a good use case and hope to see some real experience in the future.

All the best,
Bing

> >It is apparently time for people to start checking their filters again because
> it seems that these packets leak into other ASNs too...
> >

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 May 2013 02:12:24 +0000

> or what is involved to cause it.

Just number your internal network using ULAs and no global addresses, and then run a traceroute across it.   Global addresses on the source end, global addresses on the destination end, ULAs in the middle.   The only way to "fix" this is to break traceroute.   This does not represent brokenness.   Of course, it's just shy of brokenness—if the devices that are answering the ICMP messages in the core of the network are using ULAs for that, they would also use ULAs if they tried to *connect* to hosts outside of the core of the network.   But they are infrastructure devices—routers—so in practice they don't do this, and it isn't a problem.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 May 2013 19:00:17 -0700

> http://www.sixxs.net/tools/grh/ula/list/

Not exactly.. It's a list of people that thought the newest pez dispenser on the internet might be fun to play with for a little while. Some of them may actually be using the ULAs as described in the list. Most probably aren't.

I think I even appear in that list once or twice. I guarantee you I'm not using any ULAs at this time.

> Ok. So then a follow up question is how to provide perhaps more tutorial oriented information? RFCs, quite reasonably, provide enough information to justify what is proposed, and usually one use ca…

RFCs which document standards follow the format you describe. Informational RFCs, OTOH, can be more tutorial in nature and I don't really see much value in this one if it is not.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 May 2013 19:01:47 -0700

> In traceroutes, link-locals sometimes leak too.

Only if the intermediate routers are broken. A router should not forward the ICMP Time Exceeded message off link if it contains a link-local source address.

> actual traffic such as attempted TCP connections. Does that happen?

How is having them leak in attempted TCP connections worse than having them leak in ICMP headers? It's still an invalid header.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sat, 1 Jun 2013 02:21:06 +0000

> How is having them leak in attempted TCP connections worse than having them leak in ICMP headers? It's still an invalid header.

The ttl exceeded return packet doesn't expect a return packet of its own, so the fact that there's a "bogus" IP address on the header causes no harm, despite being technically wrong.   Filtering the packet based on the source address, on the other hand, would cause harm.   Nobody ever said life was going to be simple.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 May 2013 19:44:48 -0700

> The ttl exceeded return packet doesn't expect a return packet of its own, so the fact that there's a "bogus" IP address on the header causes no harm, despite being technically wrong.   Filtering th…

The TTL Exceeded packet shouldn't get forwarded by any router as a result of the LL Source address.

Thus it should never reach its destination.

Thus it will break traceroutes.

Thus it is harmful.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 1 Jun 2013 12:19:16 +0900

On Fri, May 31, 2013 at 11:12 AM, Ted Lemon <[email-masked]> wrote:

> Just number your internal network using ULAs and no global addresses, and
> then run a traceroute across it.   Global addresses on the source end,
> global addresses on the destination end, ULAs in the middle.   The only way
> to "fix" this is to break traceroute.   This does not represent brokenness.

RFC 4193 section 4.3 disagrees with you. It says that border routers should
drop those packets and send back ICMP unreachables.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Jun 2013 16:07:17 +1200

> Thus it should never reach its destination.

Agreed. But when it does get through, it does no particular
harm (you just see a bizarre hop in the traceroute). If it got
through in a SYN/ACK exchange, it would probably distress a user.

> Thus it will break traceroutes.

I'm not defending bad practice; just observing that it doesn't
cause a disaster in traceroute.

    Brian

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 31 May 2013 21:31:20 -0700

On 2013-05-31 21:07, Brian E Carpenter wrote:
[..]
> through in a SYN/ACK exchange, it would probably distress a user.

If such a packet gets through it means BCP38 is not applied as things
are not properly filtered.

And likely thus one can spoof at one's hearts content and that does do
lots of harm.

Greets,
 Jeroen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 May 2013 21:33:48 -0700

> are not properly filtered.

This has nothing to do with BCP38.

Any router which forwards a packet containing a link local address in the header is broken regardless of any BCP38 configuration.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 May 2013 21:33:03 -0700

> through in a SYN/ACK exchange, it would probably distress a user.

If it gets through, then it is an indication that every router between the one that sourced the packet and the recipient host is broken.

True, the packet itself is "mostly harmless", but…

> cause a disaster in trace route.

And I'm saying that if any of the routers between the LL-packet generating router and the recipient are working correctly, it does, in fact, break traceroute.

Owen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 31 May 2013 21:50:37 -0700

On 2013-05-31 21:33, Owen DeLong wrote:
>> On 2013-05-31 21:07, Brian E Carpenter wrote: [..]
>>> Agreed. But when it does get through, it does no particular harm
>>> (you just see a bizarre hop in the traceroute). If it got through
>>> in a SYN/ACK exchange, it would probably distress a user.
>> 
>> If such a packet gets through it means BCP38 is not applied as
>> things are not properly filtered.
>> 
> 

I would say it has everything to do with it actually ;)

Especially as it covers checking ALL traffic being forwarded and doing a
simple source check on them.

> Any router which forwards a packet containing a link local address in
> the header is broken regardless of any BCP38 configuration.

And BCP38 (Section 3, please read it, it is really informative ;) is
inclusive of those requirements. Of course do also take into account
BCP84 which details things a lot more.

Note that you have a fe80::/10 on every single interface, thus receiving
such packets from another box and trying to forward it to another
interface is just not right as it would fail uRPF do it being present on
multiple interfaces.

Greets,
 Jeroen

---

From: Owen DeLong <[email-masked]>
Date: Sat, 1 Jun 2013 01:05:39 -0500

My point is that link local packets shouldn't even get far enough for BCP38 to matter. Every router is required to not forward then no matter what. If the packet gets far enough into the forwarding process for your BCP38 filters to matter, then you need a software update for the router. 

Owen