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

[David Farmer <[e-mail]>]

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?

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]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================