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

["Lubashev, Igor" <[e-mail]>]

> 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: [e-mail] [mailto:[e-mail]] 
Sent: Monday, March 27, 2017 3:42 PM
To: Lee Howard <[e-mail]>
Cc: Brian E Carpenter <[e-mail]>; Lubashev, Igor <[e-mail]>; Fred Baker <[e-mail]>; [e-mail]
Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation

> <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.

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

> On 3/27/17, 3:27 PM, "v6ops on behalf of Brian E Carpenter"
> <[e-mail] on behalf of [e-mail]> wrote:
> 
>> 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
>> 
>> On 28/03/2017 09:05, Lubashev, Igor 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
>>> 
>>> 
>>> -----Original Message-----
>>> From: Fred Baker [mailto:[e-mail]]
>>> Sent: Monday, March 27, 2017 10:46 AM
>>> To: Lubashev, Igor <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 
>>> Address/Mask Notation
>>> 
>>> 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 <[e-mail]>
>>>> 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/.
>>>> 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.
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops