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

[Mark Smith <[e-mail]>]

Hi Brian,

On Thu, 12 Sept 2024 at 14:44, Brian E Carpenter
<[e-mail]> wrote:
>
> On 12-Sep-24 15:56, Mark Smith wrote:
> > Hi,
> >
> > What evidence is there that this is needed?
> >
> > The claim seems to be that IPv6 address space will run out in the near future, so it is necessary to start using 64 bit IID bits as prefix bits.
>
> No, it's that there are use cases in which subnetting a /64 is necessary as a practical matter. That is an operational assertion, hence the v6ops draft.
>

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.

Regards,
Mark.

>     Brian
>
> >
> > Why aren't IANA and the RIRs raising IPv6 address space exhaustion as an issue?
> >
> > Why has a /20 just been allocated for documentation if IPv6 address space is now already precious, despite IPv6 not being deployed as much as IPv4?
> >
> > Regards,
> > Mark.
> >
> >
> > On Thu, 12 Sept 2024, 12:52 Nagendra Kumar, <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >     Hi Gyan,
> >
> >     Thank you for the response.
> >
> >     Gyan> Correct. The assumption is the key here as in the draft we call “modified host” that are upgraded and support variable IID and that is where the Reserved2 comes into play to signal to hosts the encoded IID length to be generated by the host OS so that the appropriate shorter IID is now generated.
> >
> >     <Nagendra> Do you mean the host may have options to generate IID of varying size and the Reserved2 field based IID length advertisement will help identify the size required?. Or did I misunderstood?. Cant we have the prefix-length field as a way to identify the IID. IOW, (assuming I understood your comment), the host can use the prefix-length field to derive the IID length and can use the local/relevant mechanism to generate the IID of the required size.
> >
> >     Gyan> I agree with what you are saying above except for the fact that the host needs to support generating the shorter IID and must know when to support it which must be signaled by the network so it can accept the PIO and generate the host IPv6 address with variable IID.  AFAIK it is the same reasoning as above mentioned necessity for signaling to the host to variable IID in the Reserved2 field by overriding the “MUST” be ignored behavior for “modified” hosts.
> >
> >     <Nagendra> The "MUST" ignore statement is applicable only if the Prefix-Length + IID-Length is not equal to 128. In a heterogeneous scenario with HostA(modified) and HostB(legacy), I see the below possible options:
> >
> >     Option 1 - Using prefix-length field
> >
> >     Both will receive RA-PIO1 with [prefix1, prefix-length more than 64]. HostB will ignore and HostA will configure the IPv6 addr.
> >     Both will receive RA-PIO2 with [prefix2, prefix-length = 64]. HostB will configure the IP and HostA will decide based on the local config (ignore vs assign IPv6 from this prefix2 as well)
> >
> >     Option 2 - Using Reserved2 field
> >
> >     Both will receive RA-PIO1 with [prefix1, prefix-length = 64, Reserved2=Modified_Flags]. HostB will ignore and HostA will configure the IPv6 addr.
> >     Both will receive RA-PIO2 with [prefix2, prefix-length = 64, Reserved2=0]. HostB will configure the IP and HostA will decide based on the local config (ignore vs assign IPv6 from this prefix2 as well)
> >
> >     I think they both will serve the purpose but the former doesn't need changes to the Reserved field. Please correct me if I am missing something.
> >     Gyan> The details of the IID computation would be as you mentioned a non EUI64 format IID and would support both RFC 4941 privacy extension or RFC 7217 stable IID & RFC 8064.  We can add some more details on this into the draft in the next revision.
> >
> >     <Nagendra> Thanks for the clarification. I noticed some linux variants allow us configuring tokenized IID with subnet-mask. But I wasnt sure how the linux will react if it receives a RA-PIO with prefix-length more than 64.
> >
> >          Gyan> I think that could be possible.  Can you give an example of the use case of how that flexibility would be utilized.
> >
> >     <Nagendra>  In scenarios involving an end host connected to an edge router using P2P, the edge router generating the RA can be configured to use the first IP of the prefix. The host upon receiving the RA will have both the source address of the router and the prefix. It can use any of the remaining address in the prefix.
> >
> >     For example, RtrA----HostB is configured with prefix AAAA:BBBB:CCCC:DDDD:EEEE:1111:2222::/112
> >     RtrA assigns AAAA:BBBB:CCCC:DDDD:EEEE:1111:2222::1 and advertise AAAA:BBBB:CCCC:DDDD:EEEE:1111:2222::/112 with SA = AAAA:BBBB:CCCC:DDDD:EEEE:1111:2222::1. The host can simply choose any other address within the prefix. This may need some mechanism for the host to understand that this is P2P and it is safe to choose another address. A wild thought that popped up while exploring the options.
> >
> >     Thanks,
> >     Nagendra
> >
> >
> >
> >     On Mon, Sep 9, 2024 at 11:07 PM Gyan Mishra <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >
> >         Hi Nagendra
> >
> >         Many thanks for your comments.
> >
> >         FYI - I will be starting up some new threads on both 6MAN and v6OPS on the feedback we received during IETF 120.
> >
> >
> >         Responses in-line
> >
> >         On Mon, Sep 9, 2024 at 7:55 PM Nagendra Kumar <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >             Hi Authors,
> >
> >             We had some use case scenario that we brainstormed recently to use a prefix-length greater than /64. So I spent some time reading this draft and want to share my thoughts as below.
> >
> >
> >              Gyan> Can you elaborate on your use case scenarios?
> >
> >
> >
> >             As per RFC4861, a value of more than 64 in the "Prefix Length" field is technically not a violation. As mentioned in RFC4862 (Section 5.5.3), as long the sum of prefix-length and IID is equal to 128, it is a valid RA. The expectation (or assumption) here is that the host must have the ability to compute a non-EUI-64 format IID of length less than /64 and append to the prefix (of size more than 64) received in the RA.
> >
> >
> >              Gyan> Correct. The assumption is the key here as in the draft we call “modified host” that are upgraded and support variable IID and that is where the Reserved2 comes into play to signal to hosts the encoded IID length to be generated by the host OS so that the appropriate shorter IID is now generated.
> >
> >
> >             So I was wondering why not use the same?. I understand the challenges associated to the backward compatibility. But Tte proposal address the heterogenous scenario involving both supported and unsupported host by assigning 2 prefixes and advertise 2 PIO - one with Reserved2=0 and other with Reserved2=0+IID. I think we can achieve the same without modifying the Reserved2 field. We can advertise 2 RA-PIO with different prefix and different length. Host that does not support IID less than /64 will ignore that prefix and configure the prefix with length /64.
> >
> >
> >              Gyan> I agree with what you are saying above except for the fact that the host needs to support generating the shorter IID and must know when to support it which must be signaled by the network so it can accept the PIO and generate the host IPv6 address with variable IID.  AFAIK it is the same reasoning as above mentioned necessity for signaling to the host to variable IID in the Reserved2 field by overriding the “MUST” be ignored behavior for “modified” hosts.
> >
> >
> >
> >             The draft doesnt mention anything about the IID computation and I assume it is left to the host implementation. Do you have anything in mind or aware of any existing method that might be worth referring here?
> >
> >
> >             Gyan> The details of the IID computation would be as you mentioned a non EUI64 format IID and would support both RFC 4941 privacy extension or RFC 7217 stable IID & RFC 8064.  We can add some more details on this into the draft in the next revision.
> >
> >
> >
> >             I also think there are scenarios where the host connection is P2P and doesnt have more than 1 host connected (and so part of) to the link. Can we use a combination of prefix-length and the source-address of the RA-PIO to let the host choose any address from the prefix other than the router address?.
> >
> >
> >                 Gyan> The details of the IID computation would be as you mentioned a non EUI64 format IID and would support both RFC 4941 privacy extension or RFC 7217 stable IID & RFC 8064.  We can add some more details on this into the draft in the next revision.
> >
> >
> >
> >             Few quick typo noticed are below:
> >
> >             s/Exmaple/Example
> >             s/Terminolgoy/Terminology
> >             s/Modifiled/Modified
> >
> >
> >             Many Thanks!
> >
> >              Gyan
> >
> >
> >
> >             Thanks,
> >             Nagendra
> >             --------------------------------------------------------------------
> >             IETF IPv6 working group mailing list
> >             [e-mail] <mailto:[e-mail]>
> >             List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/ <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]/ <https://mailman3.ietf.org/mailman3/lists/[e-mail]/>
> >     --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> > --------------------------------------------------------------------