Subject: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 27 Mar 2017 06:09:14 +0000

I've uploaded a draft, suggesting we've been too tame with IPv6 addresses, treating them to be just like IPv4 addresses, only longer.

I'd like to get some feedback from the WG as to the content as well as the applicability of the subject in the WG.  The link is here: https://datatracker.ietf.org/doc/draft-lubashev-ipv6-addr-mask/.
To save a click, I am including the abstract.

Many thanks in advance for frank feedback,

-          Igor

------------------------------------
Abstract

With significantly longer IPv6 address prefixes assigned to ISPs, operators sometimes find opportunities to assign special meaning to lower-order bit patterns. Often, these bit patterns cannot be expressed as an address prefix.

This RFC introduces IPv6 Address/Mask notation that allows one to express address groupings beyond "all addresses that share a single prefix". The notation is similar to the IPv4 Address/Mask notation in its expressiveness, but its syntax is derived from the traditional Address/Prefix-length notation. The traditional Address/Prefix-length notation is a special case of the Address/Mask notation.

For example, using this notation, both 2001:db8::/32 and 2001:db8::/ffff:ffff:: have the same meaning. However, the following requires the new notation: 2001:db8::1234/ffff:ffff::ffff or, equivalently, 2001:db8::1234/32+::ffff.

---

From: Fred Baker <[email-masked]>
Date: Mon, 27 Mar 2017 10:45:34 -0500

We will be discussing a potential charter update on Wednesday. That said, the charter today is https://datatracker.ietf.org/wg/v6ops/charter/. IMHO, if the topic is addressing architecture, that would belong in 6man, but operational use of IPv6 addressing falls squarely into the remit of v6ops. 

The subject of discontiguous prefix use was a hot topic in the 1980's and early 1990's, hot enough that you will find references to it in RFCs 1716, 1812, and 2072. 1716 was the predecessor to 1812; the big difference (says the guy who edited one into the other) is the introduction of CIDR addressing, the deprecation of RIP v1, some additional commentary on routing, and a whole lot of copy editing. 2072 is an early document on network renumbering. You will find that, in general, a number of people wanted the capability, but didn't have use cases that made sense. 

If I were you, the first thing I would focus on is operational use cases. Who wants it, what is their problem, and why is this a good solution to it?

> On Mar 27, 2017, at 1:09 AM, Lubashev, Igor <[email-masked]> wrote:
> 
> I’ve uploaded a draft, suggesting we’ve been too tame with IPv6 addresses, treating them to be just like IPv4 addresses, only longer.
>  
> I’d like to get some feedback from the WG as to the content as well as the applicability of the subject in the WG.  The link is here: https://datatracker.ietf.org/doc/draft-lubashev-ipv6-addr-mask/.
> This RFC introduces IPv6 Address/Mask notation that allows one to express address groupings beyond “all addresses that share a single prefix”. The notation is similar to the IPv4 Address/Mask notation in its expressiveness, but its syntax is derived from the traditional Address/Prefix-length notation. The traditional Address/Prefix-length notation is a special case of the Address/Mask notation.
>  
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: George Michaelson <[email-masked]>
Date: Mon, 27 Mar 2017 10:58:26 -0500

How different is this, to the bitmask stuff D-T discussed recently
(like, within 5 years) which I think also some big CN nets wanted to
explore?

That model, was "prefix to the public route, but bitmap for the
internal route" in some ways. And, I think the CDN guys have models
which use the bitmaps to do smart content routing, but the overall
address reachability is under anycast. So the local-presence is dealt
with by normal BGP path, and nobody outside the AS cares about that
bitmap.

What I said at the time, and would repeat, is that it blows a giant
hole through the H/D ratio model of what is the 'right' size of
prefix, because the bitmap consumes *all* the bits under the
allocation prefix size. Thats not neccessarily wrong, and we are
hardly running out of IPs, but process says if you want to vary the
allocation unit models, you need to come into RIR process to discuss
that. Ultimately. Getting document in IETF is probably a good starting
point: its a tough barrier.

-G

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Mar 2017 11:40:11 -0500

Hi,

I support new notation that expresses a mask, different than a notation 
that expresses a prefix.

I have a simpler proposal for the notation of a mask.

The notation fe80:://10 expresses a mask that is different than the 
prefix fe80::/64.  Remark the mask fe80:://10 could mean prefix fe81::/10.

Also new fg00:://7 that can mean fc00::/7 and fd00::/7 (these are ULA 
addresses, and 'g' is a new character non-hex).

The need of mask notation different than prefix notation stems from 
difficulty of distinguishing the fe80::/10 from the fe80::/64 notation 
of link-local addresses, and of fd00::/7 and fc00::/7 of ULA addresses. 
This need is documented more in document DOI 10.13140/RG.2.2.30828.36484.

Alex

Le 27/03/2017 à 01:09, Lubashev, Igor a écrit :
> I’ve uploaded a draft, suggesting we’ve been too tame with IPv6
> addresses, treating them to be just like IPv4 addresses, only longer.
>
>
>
> I’d like to get some feedback from the WG as to the content as well as
> the applicability of the subject in the WG.  The link is here:
> https://datatracker.ietf.org/doc/draft-lubashev-ipv6-addr-mask/.
>
> With significantly longer IPv6 address prefixes assigned to ISPs,
> operators sometimes find opportunities to assign special meaning to
> lower-order bit patterns. Often, these bit patterns cannot be expressed
> as an address prefix.
>
>
>
> This RFC introduces IPv6 Address/Mask notation that allows one to
> express address groupings beyond “all addresses that share a single
> prefix”. The notation is similar to the IPv4 Address/Mask notation in
> its expressiveness, but its syntax is derived from the traditional
> Address/Prefix-length notation. The traditional Address/Prefix-length
> notation is a special case of the Address/Mask notation.
>
>
>
> For example, using this notation, both 2001:db8::/32 and
> 2001:db8::/ffff:ffff:: have the same meaning. However, the following
> requires the new notation: 2001:db8::1234/ffff:ffff::ffff or,
> equivalently, 2001:db8::1234/32+::ffff.
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 Mar 2017 05:20:10 +1100

On 28 March 2017 at 03:40, Alexandre Petrescu
<[email-masked]> wrote:
> Hi,
>
> I support new notation that expresses a mask, different than a notation that
> expresses a prefix.
>
> The notation fe80:://10 expresses a mask that is different than the prefix
> fe80::/64.  Remark the mask fe80:://10 could mean prefix fe81::/10.
>
> difficulty of distinguishing the fe80::/10 from the fe80::/64 notation of
> link-local addresses, and of fd00::/7 and fc00::/7 of ULA addresses. This
> need is documented more in document DOI 10.13140/RG.2.2.30828.36484.

I don't understand what the problem is.

fe80::/64 describes a range of 2^64 addresses.

fe80::/10 describes a range of 2^118 addresses.

The range of addresses in fe80::/64 is a subset of the range of
addresses in fe80::/10, because a /64 specifies a smaller range of
addresses than the /10 does.

There is no difference between fe80::/64 and fe80::/10, other than the
number of addresses they describe.

How is fe80::/10 a "mask" but not a prefix (technically an "address
prefix" using RFC4291 terminology)?

If your examples were fe80::/64 and fe80::/80, is fe80::/64 now not a
prefix, but a "mask"?

A prefix  by itself describes a range of addresses, but not how
they're being used. That use, if there is one, has to be provided
separately e.g.,

"fe80::/64, when in a route table, is a link-local route"

IPv4 is the same, "172.31.0.0/24" is making no statement of if or how
that range of IPv4 addresses are used.

Regards,
Mark.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 27 Mar 2017 20:05:44 +0000

Thanks Fred.  There is a lot more one can do with the bits available in IPv6 address allocations, so there will be more people with specific use cases this time around.  We have our use cases, and by starting this discussion, I am hoping that others will come forward as well.

- Igor

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Mar 2017 09:27:33 +1300

Somehow I feel this is going to be a noisy discussion, since you summarise
use cases by saying "there are use-cases where semantics are assigned to
individual bits or series of bits." This is a very good way to waste
address space even in IPv6. We shouldn't make it too easy. I'm afraid
that by defining such a notation, we will encourage people to do the
wrong thing.

Regards
   Brian

---

From: Lee Howard <[email-masked]>
Date: Mon, 27 Mar 2017 15:37:52 -0500

<not speaking from any role I hold>
The first thing I thought of was TeraStream (DT¹s forward thinking).
This also might support use cases Victor Kuarsingh had in mind when he
suggested v6ops consider things you can do in IPv6 that you can¹t do in
IPv6.

I also worry about giving away bits, but as we define use cases, I expect
they¹ll be to the right of the /48th bit, and often in the last 64 bits.
I¹m lesson concerned there.

Lee

On 3/27/17, 3:27 PM, "v6ops on behalf of Brian E Carpenter"
<[email-masked] on behalf of [email-masked]> wrote:

>> Thanks Fred.  There is a lot more one can do with the bits available in
>>IPv6 address allocations, so there will be more people with specific use
>>cases this time around.  We have our use cases, and by starting this
>>discussion, I am hoping that others will come forward as well.
>> 
>> - Igor
>> 
>> 
>> We will be discussing a potential charter update on Wednesday. That
>>said, the charter today is
>>https://datatracker.ietf.org/wg/v6ops/charter/. IMHO, if the topic is
>>addressing architecture, that would belong in 6man, but operational use
>>of IPv6 addressing falls squarely into the remit of v6ops.
>> 
>> The subject of discontiguous prefix use was a hot topic in the 1980's
>>and early 1990's, hot enough that you will find references to it in RFCs
>>1716, 1812, and 2072. 1716 was the predecessor to 1812; the big
>>difference (says the guy who edited one into the other) is the
>>introduction of CIDR addressing, the deprecation of RIP v1, some
>>additional commentary on routing, and a whole lot of copy editing. 2072
>>is an early document on network renumbering. You will find that, in
>>general, a number of people wanted the capability, but didn't have use
>>cases that made sense.
>> 
>> If I were you, the first thing I would focus on is operational use
>>cases. Who wants it, what is their problem, and why is this a good
>>solution to it?
>> 
>>> I¹ve uploaded a draft, suggesting we¹ve been too tame with IPv6
>>> I¹d like to get some feedback from the WG as to the content as well as
>>>express address groupings beyond ³all addresses that share a single
>>>prefix². The notation is similar to the IPv4 Address/Mask notation in

---

From: [email-masked]
Date: Mon, 27 Mar 2017 15:42:10 -0500

> I¹m lesson concerned there.

if we had variable length addresses we didn't need payload...

using addresses as protocol fields are going to be problematic no matter where you put them.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Mar 2017 09:52:16 +1300

I take your point, Lee, but there is a big difference between putting
CIDR into the bits beyond /48 and putting semantics there. If you
assign a semantic meaning to bit 63 you have potentially thrown away
half of your subnets. Add bit 62 and you are potentially down to 25%,
etc.

   Brian
On 28/03/2017 09:37, Lee Howard wrote:
> .

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Mar 2017 16:03:12 -0500

Le 27/03/2017 à 13:20, Mark Smith a écrit :
>> I support new notation that expresses a mask, different than a
>> notation that expresses a prefix.
>>
>> Also new fg00:://7 that can mean fc00::/7 and fd00::/7 (these are
>> ULA addresses, and 'g' is a new character non-hex).
>>
>> The need of mask notation different than prefix notation stems
>> from difficulty of distinguishing the fe80::/10 from the fe80::/64
>> notation of link-local addresses, and of fd00::/7 and fc00::/7 of
>> ULA addresses. This need is documented more in document DOI
>> 10.13140/RG.2.2.30828.36484.
>
>

YEs.

> fe80::/10 describes a range of 2^118 addresses.

YEs.

But is "fe80::/10" the only notation describing an LL "address prefix"?

I think "fe90::/10" too is an LL "address prefix". (the first 10 bits
are the same as in fe80::/10).

Also fe81, fe82... febf.

We could write feh*::/10, or fe80:://10, or some other special writing
to express that some LL prefix can be something else than fe80.

> addresses than the /10 does.

Yes.

>
> There is no difference between fe80::/64 and fe80::/10, other than
> the number of addresses they describe.

YEs.

But there is a difference in notation.

In fe80::/64 the 64 falls way beyond the first hextet.  Whereas in
fe80::/10 the 10 falls within the hextet.

That's a problem.

And it is the same problem in ULA notation fc00 and fd00, and in IPv4
172.16/12 and 172.17/12.

> prefix" using RFC4291 terminology)?

fe80::/10 is a "mask" in that the C code implementing "fe80::/10" is
used to recognize addresses as being LL, and it's not used to put in a
rt table.  The first 10bits can be seen through the mask, and all the
others are masked out.

> If your examples were fe80::/64 and fe80::/80, is fe80::/64 now not
> a prefix, but a "mask"?

Each one of 64 nad 80 could be a mask, if we used it as a mask: i.e.
recognize addresses.

Each one of 64 and 80 could be a prefix, if we used it as a prefix: i.e.
put it in the routing table.

None of the 64 and 80 falls within the LL first significant hextet, so
they dont generate the problem I described above.

> "fe80::/64, when in a route table, is a link-local route"

YEs, for Ethernet.  And one can't put fe81::/64 in a rt table on
Ethernet; but one _can_ say that fe81::/10 is a link-local address
prefix. (or I may be completely disconnected).

> IPv4 is the same, "172.31.0.0/24" is making no statement of if or
> how that range of IPv4 addresses are used.

Well, I am not sure why you refer to 172.31.0.0/24?  Maybe it is an
example for you, but I guess it hits into someone's network(?)  Or maybe
I dont understand.

But I want to say that same problem is in IPv4 too:

"172.16.0.0/12" denotes as much a private space as "172.17.0.0/12" does.
  I wonder why the RFC decided to write 172.16 and not 172.17.

On another hand, "192.168.0.0/16" falls precisely after the 168.  There
is no possibility to say e.g. "192.169.0.0/24 is private space".

Alex

> Regards, Mark.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 27 Mar 2017 21:09:00 +0000

> if we had variable length addresses we didn't need payload...

If you do not look above Layer 1, it all looks like a really big address (or a really big payload).  The point is that we have RFC6177 that allocates certain size address blocks to ISPs.  Additionally, due to the minimum Internet-routable IPv6 address prefix length, it is hardly feasible to fill the available address space with physical hosts.  So we would either have to tell operators to waste their addresses (makes no sense), or the operators are free to use available bits to represent things other than physical host IDs.

> If you assign a semantic meaning to bit 63 you have potentially thrown away half of your subnets. Add bit 62 and you are potentially down to 25%, etc.

Operators should certainly be encouraged not to do "stupid things" with their address space -- maybe an IETF draft to that effect is in order -- but some creative use of the otherwise-unusable address space is to be expected.

- Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 27, 2017 3:42 PM
To: Lee Howard <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Lubashev, Igor <[email-masked]>; Fred Baker <[email-masked]>; [email-masked]
Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation

> suggested v6ops consider things you can do in IPv6 that you can¹t do 
> in IPv6.
> 
> I also worry about giving away bits, but as we define use cases, I 
> expect they¹ll be to the right of the /48th bit, and often in the last 64 bits.

Ole

>> Somehow I feel this is going to be a noisy discussion, since you 
>> summarise use cases by saying "there are use-cases where semantics 
>> are assigned to individual bits or series of bits." This is a very 
>> good way to waste address space even in IPv6. We shouldn't make it 
>> too easy. I'm afraid that by defining such a notation, we will 
>> encourage people to do the wrong thing.
>> 
>> Regards
>>  Brian
>> 
>>> IPv6 address allocations, so there will be more people with specific 
>>> use cases this time around.  We have our use cases, and by starting 
>>> this discussion, I am hoping that others will come forward as well.
>>> 
>>> - Igor
>>> 
>>> 
>>> https://datatracker.ietf.org/wg/v6ops/charter/. IMHO, if the topic 
>>> is addressing architecture, that would belong in 6man, but 
>>> operational use of IPv6 addressing falls squarely into the remit of v6ops.
>>> 
>>> The subject of discontiguous prefix use was a hot topic in the 
>>> 1980's and early 1990's, hot enough that you will find references to 
>>> it in RFCs 1716, 1812, and 2072. 1716 was the predecessor to 1812; 
>>> the big difference (says the guy who edited one into the other) is 
>>> the introduction of CIDR addressing, the deprecation of RIP v1, some 
>>> additional commentary on routing, and a whole lot of copy editing. 
>>> 2072 is an early document on network renumbering. You will find 
>>> that, in general, a number of people wanted the capability, but 
>>> didn't have use cases that made sense.
>>> 
>>>> I¹d like to get some feedback from the WG as to the content as well 
>>>> as the applicability of the subject in the WG.  The link is here:
>>>> lower-order bit patterns. Often, these bit patterns cannot be 
>>>> expressed as an address prefix.
>>>> 
>>>> prefix². The notation is similar to the IPv4 Address/Mask notation 
>>>> in its expressiveness, but its syntax is derived from the 
>>>> traditional Address/Prefix-length notation. The traditional 
>>>> Address/Prefix-length notation is a special case of the Address/Mask notation.
>>>> 
>>>> 2001:db8::/ffff:ffff:: have the same meaning. However, the 
>>>> following requires the new notation: 2001:db8::1234/ffff:ffff::ffff 
>>>> or, equivalently, 2001:db8::1234/32+::ffff.

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Mar 2017 08:29:26 +0200

Hi,

> are the same as in fe80::/10).

Mathematically it's the same, and for good reason many implementations
do not allow entering a network where the host bits are not all-zero.

What is fe90::/10 trying to achieve?  It's the same network, just in a
notation confusing to humans.

> fe80::/10 the 10 falls within the hextet.

One thing is a /64, and one is a /10.  That's *not* the same thing.

> (or I may be completely disconnected).

There is some evidence for that.

[..]
>   I wonder why the RFC decided to write 172.16 and not 172.17.

Because 172.17 is not the right *network* address for the /12.  It's
having host bits set.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 Mar 2017 13:26:17 +0300

> cases. Who wants it, what is their problem, and why is this a good

I used non-contiguous netmasks once in my career, in 1997, in a
situation which required some odd bgp announcements, and it was a
syntactically short way of expressing what we wanted to do.  The
configuration was quickly reverted to standard mask-length netmasks
because other operations people had problems figuring out what exactly
was being announced.  Surprise is not a good thing in the operational world.

The problem description in the draft looks very site specific. It is
difficult to see how the use case is justified by the added complication
that this introduces.  There are an awful lot of text parsers out there
that expect mask lengths only.

Nick

---

From: Lee Howard <[email-masked]>
Date: Tue, 28 Mar 2017 06:08:10 -0500

>Because 172.17 is not the right *network* address for the /12.  It's

172.17.0.0/12 specifies the host with address 172.17.0.0 which lies within
the network 172.16.0.0/12.
We tend to be superstitious about hosts with an address of 0, but it is
allowed. 
I don¹t see anything in rfc4291 that reserves the :0 address from a prefix.

Both notations do describe the same prefix, but you need to know from
context whether the notation is describing a prefix or a host.

Lee

---

From: Fred Baker <[email-masked]>
Date: Tue, 28 Mar 2017 06:32:28 -0500

> On Mar 28, 2017, at 6:08 AM, Lee Howard <[email-masked]> wrote:
> 
> I donąt see anything in rfc4291 that reserves the :0 address from a prefix.

Section 2.6.1?

---

From: David Farmer <[email-masked]>
Date: Tue, 28 Mar 2017 06:53:27 -0500

Sent from my iPhone

> On Mar 28, 2017, at 06:08, Lee Howard <[email-masked]> wrote:
> 

It may not be reserved but it is at least somewhat special as it is defined as the subnet router anycast address, see RFC4291 sec 2.6.1.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Mar 2017 07:49:50 -0500

> notation confusing to humans.

Well, maybe I just want it to be different than other networks: I set on 
each host addresses fe90::/10.  Nothing wrong with that.

> One thing is a /64, and one is a /10.  That's *not* the same thing.

I agree.

> Because 172.17 is not the right *network* address for the /12.  It's

Well I disagree.  We talk about subnet mask here.

Is there some mandate to mandate that the host bits are 0 when we talk 
about the subnet mask?

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Mar 2017 14:55:34 +0200

Hi,

> Is there some mandate to mandate that the host bits are 0 when we talk 

That very much depends on what you are trying to specify.  

If you want to specify "I'm talking about that *subnet*", it makes no sense
whatsoever to have host bits set.

If you want to specify "this host has address <x> and is part of a /y"
(like in, "2001:db8::1/64"), of course you set host bits.

But talking about "the subnet 172.17.0.0/12" does not make any sense,
in particular because it's the same network as "172.16.0.0/12", and 
specifying anything else (when you talk about *the subnet*) is just
line noise.  Confusing readers at best.

Gert Doering
        -- NetMaster

---

From: Fred Baker <[email-masked]>
Date: Tue, 28 Mar 2017 07:55:58 -0500

> On Mar 28, 2017, at 7:49 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Is there some mandate to mandate that the host bits are 0 when we talk about the subnet mask?

When we're talking about subnet masks (or lengths), we aren't talking about addresses. We identify an address (which might be ::) and give it a length, but that is simply for notational convenience - if an address is important, we don't have to specify it separately. The "prefix" part would be the bitwise AND of the address and the mask or length.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 28 Mar 2017 13:15:42 +0000

Inter-domain routing is not likely to be a use case for where I see address/mask notation extensively used.  Most use cases are likely to be site-specific.  We've used it with internal firewalls, qos policies, internal routing.

Totally agree that surprises are not good things, especially because they tend not to work in surprising ways.  Hence this draft.

- Igor

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Tuesday, March 28, 2017 5:26 AM
To: Fred Baker <[email-masked]>
Cc: Lubashev, Igor <[email-masked]>; [email-masked]
Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation

> cases. Who wants it, what is their problem, and why is this a good 

I used non-contiguous netmasks once in my career, in 1997, in a situation which required some odd bgp announcements, and it was a syntactically short way of expressing what we wanted to do.  The configuration was quickly reverted to standard mask-length netmasks because other operations people had problems figuring out what exactly was being announced.  Surprise is not a good thing in the operational world.

The problem description in the draft looks very site specific. It is difficult to see how the use case is justified by the added complication that this introduces.  There are an awful lot of text parsers out there that expect mask lengths only.

Nick

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 28 Mar 2017 13:24:41 +0000

The way I put it in the draft:

'[Sec 1.1] Depending on the context, netmask and prefix length notations can specify either a "group of addresses" or "a group of addresses and a specific address within that group". ...

[Sec 4.1] To be a valid definition for just a group of addresses, the address part MUST NOT have any bits outside of the mask set."' 

So it is all about the context.  I.e. the output of "ip addr" vs "ip route" on Linux.

- Igor

---

From: Lee Howard <[email-masked]>
Date: Tue, 28 Mar 2017 08:45:44 -0500

On 3/28/17, 6:53 AM, "David Farmer" <[email-masked]> wrote:

>It may not be reserved but it is at least somewhat special as it is
>defined as the subnet router anycast address, see RFC4291 sec 2.6.1.

Ah, there it is. Thanks.

It’s still only for the ::0 on the prefix; billions of addresses ending in
:0 are allowed.
The difference between 2001:db8:1234:5678::0/64 and
2001:db8:1234:5678:9abd:def0:1234:000/64 is meaningful; the difference
between 2001:db8:1234:5678::/48 and 2001:db8:1234:5679::/48 is not; they
are both valid host addresses.

Lee

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 28 Mar 2017 14:14:11 +0000

RFC 4291 does not well define the address syntax. It combines the prefix and the address syntax into one:

Section 2.3
"      the node address      2001:0DB8:0:CD30:123:4567:89AB:CDEF
      and its subnet number 2001:0DB8:0:CD30::/60

      can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60"

This is not a good example. The prefix-length of 60 does not mean the four bits after 'CD3' must be zero. The node address with the same prefix can be also 2001:0DB8:0:CD3F:123:4567:89AB:CDEF/60. 

The prefix-length should not be used in the address syntax (e.g. use 2001:0DB8:0:CD30:123:4567:89AB:CDEF address and not 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60 address).

The prefix syntax must define that all bits outside the prefix-length must be set to zero. So, fe90::/10, fe81::/10 are not the valid LL prefixes.

With these changes, do we still need the address mask?

Dusan

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Lubashev, Igor
Sent: Tuesday, March 28, 2017 9:25 AM
To: Fred Baker; Alexandre Petrescu
Cc: v6ops list
Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation

- Igor

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Tuesday, March 28, 2017 7:56 AM
To: Alexandre Petrescu <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation

When we're talking about subnet masks (or lengths), we aren't talking about addresses. We identify an address (which might be ::) and give it a length, but that is simply for notational convenience - if an address is important, we don't have to specify it separately. The "prefix" part would be the bitwise AND of the address and the mask or length.
_______________________________________________
v6ops mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PltSWhkoDeatKmZk5zfNYvyTAwOGGXs1QxoG61Typ2k&s=9uH3IB_DbRwssRzuN8MTq_GsOzak8m7UmOaFkoX1Gro&e= 

_______________________________________________
v6ops mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PltSWhkoDeatKmZk5zfNYvyTAwOGGXs1QxoG61Typ2k&s=9uH3IB_DbRwssRzuN8MTq_GsOzak8m7UmOaFkoX1Gro&e=

---

From: [email-masked]
Date: Tue, 28 Mar 2017 09:22:55 -0500

> With these changes, do we still need the address mask?

Discontiguous masks are probably easiest to explain in the context of ACLs.

Multiple providers assign a /56. Finance department has the last /64 in that delegation.
A single ACL can then match on that with a mask of: 0:0:0:00FF::

You can imagine lots of these examples.

Cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 Mar 2017 17:06:32 +0100

Lubashev, Igor wrote:
> Inter-domain routing is not likely to be a use case for where I see
> address/mask notation extensively used.  Most use cases are likely to
> be site-specific.  We've used it with internal firewalls, qos
> policies, internal routing.

sorry, I meant company-specific rather than site-specific.  I.e. your
justification is that the draft is of interest to some companies who
create semantic classifications based on bitwise netmasking.  In my
case, inter-domain routing was the only use case I found for this
feature in either ipv4 or ipv6, over tens of companies ranging from ixp
to enterprise to mid-size SP (access, transit, content, etc), and using
a very wide range of equipment and features over twenty something years.
 Out of all that, categorisation of addresses using non-contiguous bit
selection was mildly useful on a sole occasion, but not useful enough to
want to keep the configuration in production.  Other people will have
different experiences on how often they had real operational use-cases
for this feature.

I've no doubt that Akamai could find plenty of use cases for this
feature, nor do I question Akamai's size.  But the issue that this WG
needs to consider is whether the benefits of this change are worth the
extra parser complication that would need to be built into all
text-based ipv6 address consumer code and lack of backwards
compatibility for the proposed syntax; personally, I don't think the
arguments are compelling.

Nick

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 29 Mar 2017 06:17:11 +0000

Nick Hilliard wrote:
> In my case, inter-domain routing was the only use case I found for this feature in either ipv4 or ipv6, [...] over twenty something years.

IPv6 is truly a different beast than IPv4. We've had "World IPv6 Launch Day" less than five years ago, and the only (barely) measurable IPv6 traffic we observed in our "war room" then was generated by some lonely piece of malware. We have come a very long way over the last five years. There is still a lot to do (some large ISPs still do not support IPv6!). Most people are just beginning to figure out how to operate IPv6 effectively (and some people have not even started to do so, yet).

We have qos, site-local routing, acl use cases already. I bet others soon will be finding use cases associated with setting up prefix-agnostic policies for multihoming or mobility in the absence of NAPT devices (RFC7157), especially when they are not interested in deploying NPTv6 devices (RFC6296).

But even with NPTv6 devices, there is still a problem of creating policies for "orthogonal subnetting".  For example, you want to subnet your /56 address space by department (2 octets) as well as by security domain (internal-wired, internal-wifi, guest-wired, guest-wifi, dmz, etc).  The routing policies and firewall policies would need to group addresses by different sets of bits.

> the issue that this WG needs to consider is whether the benefits of this change are worth the extra parser complication that would need to be built into all text-based ipv6 address consumer code

This is an informational draft, not a standards track draft.  The goal is not to force *all* ipv6 parsers to support it.  Instead, the goal is to provide notation guidance for systems that *want* to implement mask-based address groupings.  I.e. we do not want every vendor to invent their own notation for the same thing.

- Igor

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Tuesday, March 28, 2017 11:07 AM
To: Lubashev, Igor <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation

> policies, internal routing.

sorry, I meant company-specific rather than site-specific.  I.e. your justification is that the draft is of interest to some companies who create semantic classifications based on bitwise netmasking.  In my case, inter-domain routing was the only use case I found for this feature in either ipv4 or ipv6, over tens of companies ranging from ixp to enterprise to mid-size SP (access, transit, content, etc), and using a very wide range of equipment and features over twenty something years.
 Out of all that, categorisation of addresses using non-contiguous bit selection was mildly useful on a sole occasion, but not useful enough to want to keep the configuration in production.  Other people will have different experiences on how often they had real operational use-cases for this feature.

I've no doubt that Akamai could find plenty of use cases for this feature, nor do I question Akamai's size.  But the issue that this WG needs to consider is whether the benefits of this change are worth the extra parser complication that would need to be built into all text-based ipv6 address consumer code and lack of backwards compatibility for the proposed syntax; personally, I don't think the arguments are compelling.

Nick

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Mar 2017 18:37:06 +1100

On 27 Mar. 2017 5:09 pm, "Lubashev, Igor" <[email-masked]> wrote:

I’ve uploaded a draft, suggesting we’ve been too tame with IPv6 addresses,
treating them to be just like IPv4 addresses, only longer.

I don't think that is the case.

Things have been done with IPv6 addresses that are impossible to do with
IPv4 addresses.

If hosts use either or both temporary addresses and stable opaque
addresses, they become practically impossible to discover via unsolicited
inbound address probing.

Another example if leveraging IPv6's large address space is TARP -
"Transient Addressing for Related Processes: Improved Firewalling
by Using IPV6 and Multiple Addresses per Host'

There are others mentioned in

"Analysis of the 64-bit Boundary in IPv6 Addressing"
https://tools.ietf.org/html/rfc7421

I think grouping hosts together according to function would be a mistake of
they're accessible over the Internet. If humans are choosing the ranges,
they're likely not to be random and well distributed within the /64.
Secondly, if you discover one host in the group, it is easy to discover the
others, because they're adjacent or near adjacent.

Regards,
Mark.

I’d like to get some feedback from the WG as to the content as well as the
applicability of the subject in the WG.  The link is here:
https://datatracker.ietf.org/doc/draft-lubashev-ipv6-addr-mask/.

-          Igor

Abstract

With significantly longer IPv6 address prefixes assigned to ISPs, operators
sometimes find opportunities to assign special meaning to lower-order bit
patterns. Often, these bit patterns cannot be expressed as an address
prefix.

This RFC introduces IPv6 Address/Mask notation that allows one to express
address groupings beyond “all addresses that share a single prefix”. The
notation is similar to the IPv4 Address/Mask notation in its
expressiveness, but its syntax is derived from the traditional
Address/Prefix-length notation. The traditional Address/Prefix-length
notation is a special case of the Address/Mask notation.

For example, using this notation, both 2001:db8::/32 and
2001:db8::/ffff:ffff:: have the same meaning. However, the following
requires the new notation: 2001:db8::1234/ffff:ffff::ffff or, equivalently,
2001:db8::1234/32+::ffff.

---

From: t.petch <[email-masked]>
Date: Wed, 29 Mar 2017 09:55:08 +0100

----- Original Message -----
From: "Lubashev, Igor" <[email-masked]>
Sent: Wednesday, March 29, 2017 7:17 AM

> Nick Hilliard wrote:
> > In my case, inter-domain routing was the only use case I found for
this feature in either ipv4 or ipv6, [...] over twenty something years.
>
> IPv6 is truly a different beast than IPv4. We've had "World IPv6
Launch Day" less than five years ago, and the only (barely) measurable
IPv6 traffic we observed in our "war room" then was generated by some
lonely piece of malware. We have come a very long way over the last five
years. There is still a lot to do (some large ISPs still do not support
IPv6!). Most people are just beginning to figure out how to operate IPv6
effectively (and some people have not even started to do so, yet).
>
> We have qos, site-local routing, acl use cases already. I bet others
soon will be finding use cases associated with setting up
prefix-agnostic policies for multihoming or mobility in the absence of
NAPT devices (RFC7157), especially when they are not interested in
deploying NPTv6 devices (RFC6296).
>
> But even with NPTv6 devices, there is still a problem of creating
policies for "orthogonal subnetting".  For example, you want to subnet
your /56 address space by department (2 octets) as well as by security
domain (internal-wired, internal-wifi, guest-wired, guest-wifi, dmz,
etc).  The routing policies and firewall policies would need to group
addresses by different sets of bits.

Which is why what you are proposing is a bad idea.

You are taking an identifier, deciding that not all of it is needed and
that that part of the identifier can then be used to encode semantics.

I have seen many organisations do something similar with a variety of
identifiers over the years and come to regret it.  All those different
atttributes that a device with a given identifier may have, and which
may - will! - change over the years belong in a system designed to cope
with such data, commonly a relational database nowadays, with the
identifier doing what an identifier needs to do, identify; and be usable
for whatever usage the identifier has, be it reading on a screen, typing
into a device, handwriting on a form, acting as a key into a database
etc.

This I-D is a very bad idea.

Tom Petch

> > the issue that this WG needs to consider is whether the benefits of
this change are worth the extra parser complication that would need to
be built into all text-based ipv6 address consumer code
>
> This is an informational draft, not a standards track draft.  The goal
is not to force *all* ipv6 parsers to support it.  Instead, the goal is
to provide notation guidance for systems that *want* to implement
mask-based address groupings.  I.e. we do not want every vendor to
invent their own notation for the same thing.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Mar 2017 12:11:45 +0100

> that that part of the identifier can then be used to encode semantics.

no he's not.  He's simply using this as an example and saying that this
this draft will make it easier for people to do this sort of thing if
they want to.  That's ok as a justification and there is no problem with
people doing whatever they want to do on their networks.  Your network,
your rules.

> This I-D is a very bad idea.

No, it's an idea that would have been mostly neutral 20-odd years ago,
assuming different syntax, but is no longer feasible because we have 20
years of parser code out there that expects "/" to sit between the
network id and the mask length.

Nick

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 29 Mar 2017 15:27:06 +0000

t.petch wrote:
>> you want to subnet your /56 address space by department (2 octets) as well as by security domain
>> (internal-wired, internal-wifi, guest-wired, guest-wifi, dmz, etc).  The routing policies and firewall
>> policies would need to group addresses by different sets of bits.

> All those different atttributes that a device with a given identifier may have, and which may - will! -
> change over the years belong in a system designed to cope with such data, commonly a relational database

The job of any address registry is to embed "attributes" into addresses. Some registries are Internet-wide (assign prefixes to organizations). Some are run by ISPs (carve out their space to customers). Some are site-local (as in my example).
It would be awesome if Hardware (or Software) devices could take relational databases and allow one to specify routing, firewall, and other rules using SQL.  Regretfully, I have not seen such devices, and I am not optimistic I will see them soon.

In short, these attributes (prefixes, etc) are there because they are functional, not decorative.

Nick Hilliard wrote:
> have 20 years of parser code out there that expects "/" to sit between the network id and the mask length.

If I understand correctly, the concern is that the proposed notation (2001:db8::1/32+::f) could be misinterpreted by parsers as just 2001:db8::1/32 if they stop parsing prefixlen at a non-numeric.  This is good feedback.  Alexandre Petrescu suggested using double slashes.  That seems to have a nice property that non-supporting parsers will properly fail to parse. Would that address this concern?

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Mar 2017 16:55:43 +0100

Lubashev, Igor wrote:
> If I understand correctly, the concern is that the proposed notation
> (2001:db8::1/32+::f) could be misinterpreted by parsers as just
> 2001:db8::1/32 if they stop parsing prefixlen at a non-numeric.  This
> is good feedback.  Alexandre Petrescu suggested using double slashes.
> That seems to have a nice property that non-supporting parsers will
> properly fail to parse. Would that address this concern?

I'd prefer to see a completely different token used. Using two '/' chars
will lead to typos.

Regarding the proposal in general, I still maintain that the added
benefit of this proposal is tiny in the general case and the added
complication is substantial.  We know that the added benefit is small
because ipv6 has been around for over 20 years and it hasn't been an
substantial issue so far.

Nick

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 29 Mar 2017 16:18:32 +0000

Nick Hilliard wrote:
> I'd prefer to see a completely different token used. Using two '/' chars will lead to typos.

I welcome suggestions (hopefully this will not bike shed this thread).

> We know that the added benefit is small because ipv6 has been around
> for over 20 years and it hasn't been an substantial issue so far

It looks like we have a different perspective on the relevant timeframe to look for operational issues. The IPv6 RFC has been around for over 20 years. Most networks actually started to use IPv6 for real a few years ago (and some have not started yet).

- Igor

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 29 Mar 2017 19:29:20 -0500

Igor,

After our discussion, I agree with you that the LL prefixes could also 
be noted as:

        fe80::/ffc0::

I think this is good, because it also allows for an address like

        fe81::/ffc0::

to be interpreted as a link-local address that has the prefix fe80::/10.

But, if I understand you correctly, you mean that fe81::/ffc0:: (or 
fe81::/10 for that matter) is more an address and potentially a prefix, 
rather than simply a prefix.

To clarify that, I think the suggestion from Simon Hobson called "lowest 
value that fits" to explain why fe80::/10 means a prefix whereas 
fe81::/10 means an address _and_ a prefix should be written down.

Also, I think that it is worth noting that fe81::/10 (aka fe81::/ffc0::) 
is not an anycast address.

Alex

---

From: Fred Baker <[email-masked]>
Date: Wed, 29 Mar 2017 20:39:42 -0500

> On Mar 29, 2017, at 7:29 PM, Alexandre Petrescu <[email-masked]> wrote:
> 

Except it's not. It's site-local.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 30 Mar 2017 05:01:45 +0000

Site-local addresses are (were) fec0::/10.

The most proper way to interpret fe81::/10 is as an invalid address that falls within a range reserved for link-local addresses.  See Verifier Notes for the rejection of Errata 4406 of FRC 4291 (https://www.rfc-editor.org/errata_search.php?rfc=4291&eid=4406).

- Igor

---

From: Simon Hobson <[email-masked]>
Date: Thu, 30 Mar 2017 11:07:01 +0100

Alexandre Petrescu <[email-masked]> wrote:

> But, if I understand you correctly, you mean that fe81::/ffc0:: (or fe81::/10 for that matter) is more an address and potentially a prefix, rather than simply a prefix.
> 
> To clarify that, I think the suggestion from Simon Hobson called "lowest value that fits" to explain why fe80::/10 means a prefix whereas fe81::/10 means an address _and_ a prefix should be written down.

Exactly, if you apply the prefix mask to fe81::/10 then you get a prefix of fe80/10 and a host identifier part of 1:: which means the address isn't a network address but a host address within the subnet fe80::/10

AFAIK this is unchanged from IPv4 so it really shouldn't be a problem for anyone.

> The most proper way to interpret fe81::/10 is as an invalid address that falls within a range reserved for link-local addresses.  See Verifier Notes for the rejection of Errata 4406 of FRC 4291 (ht…

Ah, interesting.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 02:11:07 +1300

> AFAIK this is unchanged from IPv4 so it really shouldn't be a problem for anyone.

Disagree. It isn't explained correctly in RFC4291 (or rfc4291bis) in a way that anybody
can understand. And it seems very hard for a machine to understand unless it also
understands the context. (Hence the next point.)

    Brian

---

From: Simon Hobson <[email-masked]>
Date: Thu, 30 Mar 2017 14:59:00 +0100

> understands the context. (Hence the next point.)

Are we discussing the same thing, or have I missed something obvious ? I'm still really struggling to understand what the problem is - other than an inconsistency between different places where "link local address" is defined.

Surely simple bitwise AND/OR operations are exactly the sort of things that computers are very good at.

Take address, AND with a mask comprised of ten 1s and 118 0s, if the result = fe80 then it's in the link-local block.
Take address, AND with a mask of ten 0s and 118 1s, if the result is non-zero then it's a host identifier (address).

Isn't this pretty well the same process as determining if an address is within one of the provided on-link prefixes ? Take address, AND with mask with prefix-length 1s and the rest 0s, if result == the prefix then the address is within that prefix, else it isn't.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 03:37:48 +1300

> Isn't this pretty well the same process as determining if an address is within one of the provided on-link prefixes ? Take address, AND with mask with prefix-length 1s and the rest 0s, if result ==…

Yes, it's parsable. But it's very error prone when humans are in the loop.
It's badly explained in the addressing architecture and not explained at
all in RFC5952. And the interpretation is context-dependent.

Is fd63:45eb:dc15::/64 the address fd63:45eb:dc15:: (which happens to have an 
IID == 0) qualified with a /64 prefix, or the prefix fd63:45eb:dc15::/64 ?

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2017 21:35:46 +0000

> On 30 Mar 2017, at 15:37, Brian E Carpenter <[email-masked]> wrote:
> 

I agree it depends on the context, and is badly explained. 

Are you suggesting RFC5952 should require fd63:45eb:dc15::0/64 for the textual representation of the address, or…?  Section 2 of RFC5952 happens to omit examples with a trailing 0; they are all 1 :)

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 10:44:01 +1300

> Are you suggesting RFC5952 should require fd63:45eb:dc15::0/64 for the textual representation of the address, or…?  Section 2 of RFC5952 happens to omit examples with a trailing 0; they are all 1 :)

I don't know the right answer. It looks like an ambguity and walks and quacks like an ambiguity.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2017 21:46:12 +0000

> On 30 Mar 2017, at 22:44, Brian E Carpenter <[email-masked]> wrote:
> 

It is, but I suspect in most cases the context resolves it. 

Question is how you’d recommend disambiguating, which I think should be as text in 5952 were it ever updated, given it’s a representation thing.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 12:27:23 +1300

> Question is how you’d recommend disambiguating, which I think should be as text in 5952 were it ever updated, given it’s a representation thing.

I still don't know the right answer.

    Brian

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 31 Mar 2017 04:52:41 +0000

Tim Chown wrote:
> Are you suggesting RFC5952 should require fd63:45eb:dc15::0/64 for the textual representation
> of the address, or…?

No, definitely not fd63:45eb:dc15::0/64.  This cannot be right for two reasons:
1. fd63:45eb:dc15::0 is not a canonical address, per rfc5952 4.2.1.
2. Adding that '0' cannot be done in the general case. Think of fd63:45eb:dc15::2/127.

The interpretation is entirely contextual. If an address and its subnet is expected, it should be interpreted as such.  If only a subnet or prefix is expected, it should be interprested as the subnet or prefix.

That's how it can be explained, if an explanation ever makes it to a document.

- Igor

---

From: t.petch <[email-masked]>
Date: Fri, 31 Mar 2017 17:19:50 +0100

----- Original Message -----
From: "Lubashev, Igor" <[email-masked]>
Sent: Wednesday, March 29, 2017 4:27 PM

> change over the years belong in a system designed to cope with such
data, commonly a relational database

The job of any address registry is to embed "attributes" into addresses.
Some registries are Internet-wide (assign prefixes to organizations).
Some are run by ISPs (carve out their space to customers). Some are
site-local (as in my example).
It would be awesome if Hardware (or Software) devices could take
relational databases and allow one to specify routing, firewall, and
other rules using SQL.  Regretfully, I have not seen such devices, and I
am not optimistic I will see them soon.

In short, these attributes (prefixes, etc) are there because they are
functional, not decorative.

<tp>

Igor

No, an address registry does not embed anything in anything (ditto an
ISP).  Its job is to manage an address space (or a namespace) and decide
who can use which part and how the parts are identified; in this case,
it is how many of the leading bits will be used
as an identifier and what the values therof represent.

You want to embed further semantics which, my experience tells me, will
not last the test of time.

And I know plenty of organisations which use (relational) databases to
store the relevant information about the parts of their organisations
and the systems therein; there is no need for this to be online to a
networking box for it to be right solution to storing such information

Tom Petch.

<snip>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Apr 2017 10:24:01 +1300

> 1. fd63:45eb:dc15::0 is not a canonical address, per rfc5952 4.2.1.

Agreed, it is not canonical, but I believe it is valid. I included the "0" to make
it clear that the IID is all zeros.

> 2. Adding that '0' cannot be done in the general case. Think of fd63:45eb:dc15::2/127.

True, but irrelevant to my example.
 
> The interpretation is entirely contextual. 

That is exactly the problem. A syntax whose semantics depends on context is very
error-prone when it appears in the human/computer interface.

   Brian

> If an address and its subnet is expected, it should be interpreted as such.  If only a subnet or prefix is expected, it should be interprested as the subnet or prefix.
>

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 31 Mar 2017 22:07:32 +0000 (UTC)

I agree that having a contextual interpretation of any notation is confusing and unfortunate. At this point, if we are to recommend anything, it must be backward and forward compatible.

> Adding that '0' cannot be done in the general case.
I thought it was relevant in a sense that if we do recommend a change, it should "work" in all cases. Hence, "just add a non-canonical zero in the last nibble" does not fit that bill.
However, if this is the best we can do, I could go along with this recommendation, which could make things clearer for humans in most cases, though not all.
- Igor

Sent from Yahoo Mail on Android 

 

  Brian

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 31 Mar 2017 22:44:19 +0000

t.petch wrote:
> I know plenty of organisations which use (relational) databases to store
> the relevant information about the parts of their organisations and the
> systems therein; there is no need for this to be online to a networking
> box for it to be right solution to storing such information

You are thinking of some decorative attributes.  I am talking about very functional attributes -- attributes that a networking device needs to implement a policy, at line rate.  These attributes are no different from the prefix attribute assigned by a registry (whose purpose is not only to limit the number of global addresses owned by an entity but also to allow network boxes to route traffic).  If I have groups of devices in multiple subnets share a need for a common policy (firewall policy, qos policy, routing policy, whatever), I need to configure my policy-enforcement device in terms of a discontinuous bitmap.

Will I ever find myself in a need to change / update my addressing scheme?  I really hope so -- that would mean I am doing well and my needs are evolving. My goal is not to make something that will serve me *forever* but to build something that serves the needs I have now and allows for a smooth transition to accommodate tomorrow's needs I cannot anticipate today.

Just in case anyone is wondering, there are tens of thousands of instances of systems using the concepts I am describing (IPv6 address/bitmap-defined policies) deployed all over the Internet today.  They are serving a very large portion of the Internet IPv6 web content.  I am not very interested in hearing that there is no need for such systems.  There will be such systems from other vendors in our future.  I would like to give IETF community an opportunity to decide on the best way to express such policies, before vendors start to invent their own ways.

- Igor