Subject: Re: New Version Notification for draft-petrescu-6man-ll-prefix-len-15.txt

From: Gyan Mishra <[email-masked]>
Date: Thu, 2 May 2019 10:02:55 -0400

Phil

I agree with what you are saying that a valid use case is really required to make a use case for subnet id.

Alex 

Can we add this use case into the draft that I had mentioned before.

So the use case is to make the next hop for routing protocols intuitive by mapping Thur global unicast address into the both the subnet and station id field.  Previously in this scenario we ended up having to drop the 1st 16 bits of the global unicast address as 16 bits ended up bleeding into the all 0s station id violating RFc 4291.

So with this new draft the entire global unicast address 64 bit field plus the station id now up to 54 bits can be mapped into the link local address.

Example below:

Previously with RFC 4291

2600:80b:100:1::1

Mapped into link local we had to the 1st 16 bits

fe80::80b:100:1:1

With this new rfc we can now map the entire global unicast field into the link local address making the address intuitive as to what your next hop is as you know what your global unicast address and not EUI64 station is.

fe80::2600:80b:100:1:1

So now with this RFC with let’s say all 16 bit nibbles in use we in a use case like this we could still map the entire global unicast address into the link local address and not have to drop any bits.

Global unicast 
2600:80b:1000:1101::1:2:3

Mapped into link local 
fe80::2600:80b:1000:1101:1:2:3

Thank you

Gyan
Sent from my iPhone

On Apr 30, 2019, at 5:07 AM, Philip Homburg <[email-masked]> wrote:

>> We would like to briefly inform you that we updated the draft about the 
>> prefix length of the LL addresses.
> 
> After reading draft-petrescu-6man-ll-prefix-len-15, this is my impression o
> the draft:
> 
> Section 3, Problem Statement, limits itself to manual configuration. Then
> it describes how manual configuration sometimes benefits from a Subnet ID.
> 
> This is fine. In the case of manual configuration, there is no need to judge
> how the subnet ID is allocated or kept consistent. At the same time, manual
> configuration is a very limited use case.
> 
> Then Section 4, Kinds of Solutions, gives a description of using fe80::1:2/64
> where '1' is the subnet ID and '2' an interface ID.
> 
> The only comment on using this apporach is 'invade the IID with a Subnet ID'.
> To me that doesn't seem to be a technical issue. The total IID space is
> 64 bits. We are talking about manual configuration. So even if the lower
> 32 bits would be used for an IPv4 address there is still plenty of space
> for a subnet ID. It is very unlikely that with manual configuration it would
> be impossible to find a split between the subnet ID and any other ID that is
> required.
> 
> So it seems to me that the problem described in Section 3 can be solved using
> fe80::1:2/64 and this draft is unnecessary.
> 
> Alternatively, the authors can explain how they tried to use fe80::1:2/64
> in practice and it lead to problems.
> 
> There is one statement that I found confusing: "Other solutions involve a
> hidden 'scope_id' and the use of special syntax ('%') to denote an interface."
> 
> As far as I know, in all operating systems, the use of a link local address
> requires the use of a scope_id. This is because exactly the same prefix is
> implicitly configured on all interface. So scope_id is far from hidden. It
> is required.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------