[IPv6]Re: [EXT] Re: Mail regarding draft-mishra-6man-variable-iids

[Jeremy Duncan <[e-mail]>]

Scott-

The RFC does not say that those bits MUST NOT be used. That’s the ambiguity I stated. And it obviously needed to be stated for the reason I gave below.

However, I think you might be missing the point I made about how these assumptions can cause significant issues down the road. The industry has been pounding the /64 reserved for host bits for 25 years and vendors have implemented it that way for 25 years. So we start messing around on those edges, we can end up with unintended consequences.

That is the only point I am trying to make here.


-Jeremy

From: Morizot Timothy S <Timothy.S.Morizot=[e-mail]>
Sent: Thursday, September 12, 2024 9:27 AM
To: Jeremy Duncan <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [EXT] [IPv6]Re: Mail regarding draft-mishra-6man-variable-iids

[EXTERNAL] Verify links and attachments with sender.


While the entire /10 is reserved and could have additional uses defined at some future point I suppose, there is nothing ambiguous in the RFC specification of a link local address. The 54 bits between the prefix and the last 64 bits are explicitly defined as ‘0’. The binary value of the entire first 64 bits is specified in the RFC. I’m not sure how the authors could make it any clearer. And the reason is logically obvious. Link communication is how devices learn anything about the link. That means they have to all agree *before* any communication occurs, what the link prefix is.



Use anything else at your own risk as the example you gave illustrates.



Scott



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.



-----Original Message-----
From: Jeremy Duncan <jduncan=[e-mail]<mailto:jduncan=[e-mail]>>
Sent: Thursday, September 12, 2024 8:07 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT] [IPv6]Re: Mail regarding draft-mishra-6man-variable-iids



Hi all-



While I understand the problem statements and practical usages, I'd like to caution about some unintended consequences for this one reason: vendor implementations have made certain assumptions based on the sanctity of the /64 host bits and subnet bits. Rightfully or wrongly, the last 25 years of implementations have considered /64 host bits holy and impenetrable by many in the industry.



We have seen some of this behavior in reverse in the real-world recently. For example, a US federal organization decided to go into the network-bits of the link local addressing space for naming convention purposes. Like fe80::1:2:3:4:5/64



However, is this illegal? not really. Sec 2.5.6 of RFC 4192 has some ambiguity here.

https://www.rfc-editor.org/rfc/rfc4291#section-2.5.6



Unlike the other address copes, it doesn't reserve the 54 bits between fe80 and host bits for subnets like it does the other or state that something other than zeros must not go here.



Well this caused a denial of service that took months to resolve because vendor A received a packet from fe80::1:2:3:4:5/64 and vendor B did an NS for fe80::2:3:4:5/64 because those 54 bits were not to be used. Obviously, this is not the same issue but does go to the point where unintended consequences can cause more issues that it solves because certain assumptions have been made over 25 years of IPv6.



I am not saying I don't agree the statement and solution has merit.  I am merely asking us all to be very deliberative about how this could affect the production implementations that exist and have been built on for the last 25 years given that IPv6 is not a playground anymore.







-Jeremy





-----Original Message-----

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

Sent: Thursday, September 12, 2024 8:07 AM

To: [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

Subject: [IPv6]Re: Mail regarding draft-mishra-6man-variable-iids



[EXTERNAL] Verify links and attachments with sender.



>>     The "practical" reasons for subnetting a /64 only exist in networks

>>     that have been precious with their IPv6 space, because they're

>>     habitually treating IPv6 address space like they've needed to treat

>>     IPv4's for the past few decades, rather than being objective.

>>

>>     By trying to accommodate those networks we're endorsing their

>>     irrationality about how big IPv6's address space really is, and we're

>>     imposing costs onto those who are being rational. They will be

>>     indirectly bearing the costs of host and router upgrades to support

>>     subdividing 64 bit IIDs, even though they haven't incurred those

>>     costs.

>>

>>

>> +1. Additionally, subnetting /64s will only work until those same networks start using /80. At that point, we will be in the same situation, except we can substitute "/64" with "/80".

>

> (+1)

>

> Maybe I've just not been paying enough attention, but I've been

> waiting to see anyone mention RFC2464 "Transmission of IPv6 Packets

> over Ethernet Networks" mandating 64bit IIDs.

>

> Router silicon redesign seems to be a serious bottleneck, is relaxing

> RFC2464 really feasible?



Router silicon is *already* handling longer masks than /64 (and has been for many years). A box that could only route IPv6 with longest netmask of /64 would not be purchased by us, and I suspect the same is the case for many other ISPs.



So there is nothing new here.



Steinar Haug, AS2116



--------------------------------------------------------------------

IETF IPv6 working group mailing list

[e-mail]<mailto:[e-mail]>

List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/

--------------------------------------------------------------------

--------------------------------------------------------------------

IETF IPv6 working group mailing list

[e-mail]<mailto:[e-mail]>

List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/

--------------------------------------------------------------------