Re: [v6ops] [homenet] Tsinghua work on source/destination routing

[Owen DeLong <[e-mail]>]

>> to ensure that the packet is not repeated by a broken router (apart
>> from protocols that ask to have it set to 255 and have the receiving
>> host check for that value). Also, upstream network's BCP 38
> 
> I'd note, from purely architectural point of view, that it's totally
> valid a packet that has a link-local address is forwarded, as long as
> the packet remains in the originating link zone.  That would be a very
> unlikely case in practice, but can still happen, e.g., when a host
> sends all packets to a router, expecting the router to forward it back
> to the same link toward the destination.  RFC 4007 mentions such
> cases.

That is not correct…

RFC 4291 says:

2.5.6.  Link-Local IPv6 Unicast Addresses

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as automatic address configuration,
   neighbor discovery, or when no routers are present.

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

It is quite clear that a packet with a link-local address in either field MUST not be forwarded.

>> implementation sounds suspect, and I'm with Jen in wondering why a
>> router forwarded the packet in the first place.
> 
> It's not surprising to me since the source address is not needed as
> long as routing decision is only made based on the destination
> address.  I noticed one popular router vendor didn't implement this
> restriction of RFC 4007 correctly many years ago and even reported it
> to the vendor, but (assuming it's still not fixed) just being "non
> compliant" is probably not convincing enough for them to introduce
> additional overhead in their forwarding logic.

It's surprising to me and it means that the router is, by definition, not compliant with RFC 4291, ergo, the router is broken.

Owen