Re: <draft-ietf-6man-rfc4291bis-09.txt>

[David Farmer <[e-mail]>]

On Mon, Jul 24, 2017 at 9:18 AM, David Farmer <[e-mail]> wrote:

>
>
> On Mon, Jul 24, 2017 at 3:47 AM, t.petch <[e-mail]> wrote:
>
>> ----- Original Message -----
>> From: "David Farmer" <[e-mail]>
>> To: "james woodyatt" <[e-mail]>
>> Cc: "IPv6 List" <[e-mail]>
>> Sent: Saturday, July 22, 2017 9:54 PM
>>
>> On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt <[e-mail]> wrote:
>>
>> > On Jul 19, 2017, at 09:57, Brian E Carpenter
>> <[e-mail]>
>> > wrote:
>> >
>> > On 19/07/2017 18:22, james woodyatt wrote:
>> >
>> > On Jul 19, 2017, at 01:15, Brian E Carpenter
>> <[e-mail]>
>> > wrote:
>> >
>> >
>> > Hmm. Let's consider a case in which the last-hop route to a given LAN
>> has
>> > a prefix of
>> > length, say, /80. What is the name of the bit-string from bits 81
>> through
>> > 127 of the
>> > host address? If they aren't called the "IID" what are they called?
>> >
>> >
>> > If have yet to find where RFC 4291 clearly names the part of an IPv6
>> > address that follows a *routing* prefix apart from a *subnet* prefix.
>> > Moreover, the phrase “last-hop route to a given LAN” is not equivalent
>> to
>> > the concept of a subnet, and such a routing prefix is not equivalent
>> to a
>> > subnet prefix. As RFC 5942 clarifies.
>> >
>> >
>> > Agreed, but I phrased my question in full knowledge of that. What do
>> we
>> > call those trailing
>> > bits of the address? (I was reading the source of the Python
>> 'ipaddress'
>> > module yesterday,
>> > and saw a comment about 'host bits', but that seems very 20th century,
>> > given that the
>> > IPv6 architecture refers to interfaces.)
>> >
>> >
>> > I’ve been mentally using “address suffix” for this concept, and I find
>> > that I rarely have much need for it. I suppose if I were using on-link
>> > prefixes longer than /64, then I’d need it so I could differentiate
>> between
>> > the 64-bit Interface ID and the shorter part of the address that
>> follows
>> > the on-link prefix.
>> >
>>
>> I think I'd prefer to call the righthand side of both a subnet prefix
>> and a
>> on-link prefix an interface identifier, because in both case it is a
>> node's
>> interface that is being identified.  Then generically they are interface
>> identifiers, if you are referring to a specific aspect it is qualified
>> with
>> the aspect.
>>
>> generically;
>>
>> prefix / interface identifier
>>
>> with specific aspects being referred to as;
>>
>> subnet prefix / subnet interface identifier
>> on-link prefix / on-link interface identifier
>>
>> Then it would be subnet interface identifiers that are 64 bits, except
>> ...
>> and on-link interface identifiers are any length.
>>
>> That is basically the assertion that started this part of the
>> discussion,
>> and that did fly with at least some.
>>
>> So, I've been kicking around other ideas, because if the righthand side
>> of
>> an on-link prefix isn't an interface identifier, it needs another name.
>> How
>> about;
>>
>> node identifier
>> on-link identifier
>> host identifier
>> on-link node
>> on-link host
>>
>> I think I like on-link node best, but on-link identifier is a close
>> second
>> for me.
>>
>> so;
>>
>> subnet prefix / interface identifier
>> on-link prefix / on-link node
>>
>> or;
>>
>> subnet prefix / interface identifier
>> on-link prefix / on-link identifier
>>
>> What do others think?
>>
>> <tp>
>>
>> How would that cope with address assignment prefixes being longer than
>> on-link prefixes?
>>
>
> You say an address assignment prefix longer than the on-link prefix, but
> then you describe below a on-link prefix longer than the address assignment
> prefixes below, which do you really mean?
>

Sorry, I should have had caffeine before doing email. :(

/64 address assignment prefixes are longer than /60 on-link prefixes.

I think everything below is correct though. :)


> My on-link prefix is /60 but for address assignment I use a /64 and have
>> one /64 for network management devices, another for print servers,
>> another for routers, one or more for hosts and so on.
>>
>> Tom Petch
>>
>
> To achieve the desired result you state above, a /60 on-link prefix and
> /64 address assignment prefixes,  I don't see how you would be able to use
> SLAAC, but you could achieve what you state above with DHCPv6, or manual
> config.
>
> Having the on-link prefix as a /60 just says that all 16 /64s are
> associated with that link. But SLAAC devices will have no knowledge of
> which of the 16 /64 they are suppose to generate an addresses from.
>
> You could have a PIO with a /60 prefix with the L flag set, and 1 to 16
> /64 PIOs with the A flag set. Most devices will generate addresses on all
> the /64s that have an A flag set.  Printers will have no way to know they
> should only use the first /64 verses the last /64 or any in between. Same
> for management devices.  Now you could manually assign devices to different
> /64s or use DHCPv6.  You could use DHCP for the hosts, but if set a PIO
> with a A flag for the hosts on one /64 you would need to configure the
> non-hosts to not use SLAAC, which is not a trivial thing to do as far as
> I've seen on most devices.
>
> What we name the righthand side of a on-link prefix isn't going to change
> how it works, as Shakespeare says "a rose by any other name would smell as
> sweet", we just need to agree its called a rose.
>
> Thanks.
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone] <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>



-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================