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

[George Michaelson <[e-mail]>]

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

On Mon, Mar 27, 2017 at 10:45 AM, Fred Baker <[e-mail]> wrote:
> 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