Subject: [v6ops] rfc7084-bis and homenet

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 14 Apr 2017 00:44:06 +0000

> Where I might be departing from her on... [not introducing "burdensome" requirements] ...(not sure) is that I don’t 
> believe it’s a good idea, or even really possible, to publish RFC 7084-bis without adding some non-recurring costs to 
> the development of new CE routers that implement the more recent HOMENET standards for the LAN interfaces in home networks.

> Maybe there are operators that don’t “want” their CE routers to participate in the HNCP distributed 
> consensus protocol on the LAN interface. If there are such operators, then I think it would help to surface 
> their objections sooner rather than later.

Where I struggle is the chicken and egg thing. This operator, at least, isn't seeing a strong need to be a driver of homenet protocols. And it's not me, personally. It's that I can't figure out how to convince the people who do CE router release planning or who issue the RFPs. It's possible for a router vendor to say they see a need, have developed it, and will just include it. But I haven't seen the router vendors saying that. If no-one who is in a decision-making capacity is convinced, it will not happen. RFCs like this have minimal effectiveness.

What we need is a convincing argument as to why a CE router will be desired by regular people if it has the homenet stuff.

One of the biggest problems I see that homenet solutions might be able to solve for regular people (and I don't think it does quite yet but I could be wrong) is helping divvy up a single /64 among multiple routers. But this would also require the ability to send a subset of a /64 in RA and hosts do a stateless autoconfiguration address assignment but recognizing that it doesn't have a /64 to use and can't do EUI-64 (so it isn't RFC 4862 SLAAC). If we could figure out how to do this without breaking existing stuff, I think I could sell it. I keep seeing those 3GPP deployments with just the single /64 and how some ISPs are saying /64 seems like plenty and think it would be worth a try to divvy it up rather than railing at those stupid ISPs (which hasn't been real successful to date).

<Warning: the above content was written after work and after wine; it's just a random thought.>
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Apr 2017 21:33:08 -0400

On Apr 13, 2017, at 8:44 PM, STARK, BARBARA H <[email-masked]> wrote:
> One of the biggest problems I see that homenet solutions might be able to solve for regular people (and I don't think it does quite yet but I could be wrong) is helping divvy up a single /64 among multiple routers.

It's entirely possible that if ISPs start handing out single /64s to broadband customers, a market for this solution will arise.   That would be a tremendously bad outcome, however, and also risks triggering the spread of the much simpler solution of just doing NAT.

Consequently, I'm disinclined to make this a target use case.

I think it's more likely that the homenet use case will be applicable to high-end routers like the ones Google are starting to sell.   I believe that they are driving this market, and homenet would be a nice deployment model.   But not until we have it.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 14 Apr 2017 01:40:29 +0000

> I think it's more likely that the homenet use case will be applicable to high-end routers 
> like the ones Google are starting to sell.   I believe that they are driving this market, and 
> homenet would be a nice deployment model.   But not until we have it.

This opinion gives me ammunition to push back against James W's proposal to require HNCP in a 7084-bis.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Apr 2017 22:18:14 -0400

> This opinion gives me ammunition to push back against James W's proposal to require HNCP in a 7084-bis.

Personally I think that would be premature.   I don't know what the requirement would say.

---

From: Fred Baker <[email-masked]>
Date: Thu, 13 Apr 2017 19:42:06 -0700

> One of the biggest problems I see that homenet solutions might be able to solve for regular people (and I don't think it does quite yet but I could be wrong) is helping divvy up a single /64 among…

A single /64 to a telephone that has a hot spot behind it is not too hard. The telephone gets one of the 2^64 IIDs and is therefore in the same subnet as the LAN. From a routing perspective, it is the router that gets a packet to the destination address in the hot spot.

What you request is of course trivial if we can put a prefix longer than /64 on a LAN, or if we can get a prefix shorter than /64 from the ISP. Other ISPs that I have spoken with suggest that one gets pretty much what one asks for - if you ask for a /64, that's what you get, if you ask for a /63 you get a /60, and if you ask for a /59, you get a /56. A prefix longer than a /64 will get disapproving commentary in v6ops or 6man. What does allocating a prefix shorter than /64 to a subscriber get in your favorite network?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Apr 2017 16:14:32 +1200

> What we need is a convincing argument as to why a CE router will be desired by regular people if it has the homenet stuff.

If they desire to build a multi-router network in their home or small office, it would be easiest if all their routers support homenet and one of them happens to be connected as the CE. At some point in history, that may become the common case, but I don't see it happening just yet. For 7084bis, making homenet a MAY is realistic, with a hint that 7084bis-bis is likely to make it a SHOULD.

> One of the biggest problems I see that homenet solutions might be able to solve for regular people (and I don't think it does quite yet but I could be wrong) is helping divvy up a single /64 among multiple routers. But this would also require the ability to send a subset of a /64 in RA and hosts do a stateless autoconfiguration address assignment but recognizing that it doesn't have a /64 to use and can't do EUI-64 (so it isn't RFC 4862 SLAAC). 

Being picky, it *is* RFC 4862 SLAAC; SLAAC is carefully defined without a specific IID size.

It *isn't* consistent with RFC 4291 unless the length is 64. See several hundred messages about 4291bis...

> If we could figure out how to do this without breaking existing stuff, I think I could sell it. I keep seeing those 3GPP deployments with just the single /64 and how some ISPs are saying /64 seems like plenty and think it would be worth a try to divvy it up rather than railing at those stupid ISPs (which hasn't been real successful to date).

That isn't going to happen on the timescale of 7084bis, IMNSHO. For now, ISPs need to get real and supply
a /48 (we have about 15 trillion in stock) or /56 (we have almost 4 quadrillion) for customers with subnets. I suspect the ISPs will shift on this as the market evolves.

   Brian

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Apr 2017 07:44:00 +0000

Hello Barbara:

An alternate to subnetting the /64 could be to route to the host. That's what we do in route-over IOT solutions, using RPL between the routers. 

Networks with thousands of nodes are deployed like that around you, for instance in smart metering industry.

For home, using RPL would be consistent with the use of ANIMA and help build a trustable network. It would also be consistent with RPL-based Home IOT.

Note: when the host moves rapidly, support for RFC-6775-update can improve the user experience by immediately signaling the freshest location. OTOH, If you subnet the /64, the host renumbers to the new subnet and loses its current connections.

Regards,

Pascal

> Le 14 avr. 2017 à 02:44, STARK, BARBARA H <[email-masked]> a écrit :
> 
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 14 Apr 2017 13:43:26 +0000

>  Other ISPs that
> I have spoken with suggest that one gets pretty much what one asks for - if
> you ask for a /64, that's what you get, if you ask for a /63 you get a /60, and if
> you ask for a /59, you get a /56. A prefix longer than a /64 will get
> disapproving commentary in v6ops or 6man. What does allocating a prefix
> shorter than /64 to a subscriber get in your favorite network?

<sigh> Please don't misconstrue what I said as "this is what AT&T wants".
It's not about AT&T. AT&T hat way, way off.
Consumer hat firmly in place.
As a consumer and an individual, I see what options consumers are being provided around the world.
Many people are going to LTE for their broadband access (using a USB LTE radio attached to one of those easy-to-get routers that has drivers for the USB device from their LTE provider). I'm not personally aware of any LTE providers who are providing more than a /64. AFAIK, the 3GPP release that supports IA_PD still hasn't been deployed.
There are other ISPs that are supplying whatever prefixes they're supplying. 
Most consumers really don't care (not about IPv6, and certainly not about IPv6 prefix lengths). So the population of people who care is small. 
Because of this, there are not strong market drivers to speed up development of IA_PD features in 3GPP releases and deploy them. There's not even a strong market driver to get equipment vendors to actually deliver GPON or VDSL2 access equipment that properly (i.e., it actually works and doesn't have bugs) supports IPv6 (which forces continued use of technologies like 6rd, which do not allow for variation in provided prefix).

For years now, there has been a dominant view in IETF that the correct approach for consumers to take who want to have multiple routers (multiple /64 prefixes) is to whine, complain, use empty threats, and beg to try to get a bigger prefix. In order to force consumers to take this approach, this dominant view has successfully prevented consumers from getting tools that would allow them to maximize use of a /64, if they have one. Whining and begging is only effective if many people do it, and if consumers had tools to deal with the problem on their own, they would stop whining and begging, which would reduce pressure on ISPs, which would reduce pressure on vendors to deliver working equipment to ISPs. Therefore, to ensure continued whining and begging, it's very important to keep out of consumers' hands any tool that would allow them to make full use of the 2^64 addresses in a /64.

As a consumer, I really don't like being used as a pawn by vocal people who want to maximize their voice by forcing me to add mine to theirs. I just want the tools that will let me easily use my 2^64 addresses the way I want. 
Barbara

---

From: james woodyatt <[email-masked]>
Date: Fri, 14 Apr 2017 09:53:58 -0700

On Apr 13, 2017, at 19:42, Fred Baker <[email-masked]> wrote:
> 
> Other ISPs that I have spoken with suggest that one gets pretty much what one asks for […]

This is, of course, a misrepresentation of how it actually works. Here’s how it actually works:

p1. There is no reason whatsoever to ask for a prefix longer than /48, so everyone asks for a /48.

p2. No service provider accepts the rationale for assigning every subscriber a /48, so everyone gets a longer prefix.

p3. Therefore, everyone gets the shortest prefix their service provider is willing to assign them, which may be as long as a /64 regardless of what is requested.

One gets whatever the ISP decides, not what one asks for. And if you don’t like your ISP, then you can petition your local telecom regulatory agency to allow a competitor to operate in your market, hopefully one that provides shorter prefixes.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 14 Apr 2017 19:25:09 +0200

Fully agree with James.

I’ve analyzed that thru a survey that I’ve already mention in this list before. The latest slide set and video of the presentation at RIPE is here:
https://ripe73.ripe.net/archives/video/1242

One of the results that this survey shows, is that many (1/3) ISPs (99% in wireline access technologies), provide only a /64 to the customers. Here is the relevant data (slide 15):
- 33% /64 mainly in LACNIC, some countries in APNIC
- 35% /56 mainly ARIN/RIPE NCC
- 22% /48 mainly “more advanced” countries (Australia, New Zealand, Germany, Finland, Denmark, France, UK, China, Japan)
- 10% provide “other” lengths (including some /128)

In my opinion, despite how much effort in IPv6 training has been done in LACNIC and APNIC, most of the ISPs still continue to see IPv6 as IPv4, and this is the main reason this happens, in addition to reasons related to wrongly understood sales/marketing rationales.

We are also working at RIPE BCOP WG in a relevant document. Latest public version is here:
https://www.ripe.net/ripe/mail/archives/bcop/2017-March/000159.html

If we talk about the 3GPP context, there is a nice document, RFC7849, that, if followed, could sort out the problem. In fact, a few ISPs and very few vendors, are actually following it for broadband deployment with 3GPP.

Unfortunately, this document was and independent submission, not sure to recall correctly all the history details, but my opinion is that it will make a lot of sense to reclassify it as a standard track.

⇒ Question for the co-chairs and authors. It will be possible to do so?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de james woodyatt <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 14 de abril de 2017, 18:53
Para: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] rfc7084-bis and homenet

    

    

    
    --james woodyatt <[email-masked]>

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: David Farmer <[email-masked]>
Date: Fri, 14 Apr 2017 12:55:16 -0500

> p1. There is no reason whatsoever to ask for a prefix longer than /48, so

I disagree there are plenty to reasons to not hand out /48s, even some
valid ones, and perpetuating that myth that handing out /48s is the only
way to go is not helpful.  Now there should be no reason to not give out
more than just one /64.

A side note: at UMN we still have IPv4 /24s given out to departments over
25 years ago, before VLSM, and working with the departments to recover
unused address space is much harder than pulling teeth.  So internally, I
want IPv6 isn't a good enough reason for us to allocate a /48 for a
department, we will allocate as many /64 as they want and even a /56 if the
ask for it.  But I require some level of justification for a /48, like a
plan to use at least a couple dozen or so /64s, because it will be a big
pain to ever get them to change once we give a department a /48.

> p2. No service provider accepts the rationale for assigning every
> subscriber a /48, so everyone gets a longer prefix.
>

So, /48, /52, /56, and /60 are all reasonable options, for providers to
hand out, this is essentally waht RFC 6177 says.

> p3. Therefore, everyone gets the shortest prefix their service provider is
> willing to assign them, which may be as long as a /64 regardless of what is
> requested.
>
> One gets whatever the ISP decides, not what one asks for. And if you don’t
> like your ISP, then you can petition your local telecom regulatory agency
> to allow a competitor to operate in your market, hopefully one that
> provides shorter prefixes.
>

Part of the reason for this is a number of the CE routers don't work right
if you give them something more than a /64, ISPs don't want any breakage.
This is basically the same reason you don't want to do DHCPv6 on Android,
providers aren't any more unreasonable than you are, they just have a
different point of view on the world.

So if we really want to fix this rfc7084-bis needs a SHOULD support prefix
delegation of any length between /48 and /64, and MUST support prefix
delegations of /48, /52, /56, /60, and /64.

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

---

From: james woodyatt <[email-masked]>
Date: Fri, 14 Apr 2017 11:28:24 -0700

On Apr 14, 2017, at 10:55, David Farmer <[email-masked]> wrote:
> On Fri, Apr 14, 2017 at 11:53 AM, james woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
> […]
> I disagree there are plenty to reasons to not hand out /48s, even some valid ones, and perpetuating that myth that handing out /48s is the only way to go is not helpful. […]

Unfair. I didn’t say there’s no reason for providers to refuse some or all requests for /48s. I said there’s no reason for a subscriber to ask for a prefix longer than a /48.

As it happens, I personally find none of the architectural reasoning for delegating prefixes longer than /48 to retail subscribers at all convincing, but please be fair: I’m not disputing that other people here make different value judgments than I do about whose interests in the architecture of the Internet should be prioritized over the interests of everyone else.

---

From: David Farmer <[email-masked]>
Date: Fri, 14 Apr 2017 14:42:57 -0500

On Fri, Apr 14, 2017 at 1:28 PM, james woodyatt <[email-masked]> wrote:

> way to go is not helpful. […]
>
>
> Unfair. I didn’t say there’s no reason for providers to refuse some or all
> requests for /48s. I said there’s no reason for a subscriber to ask for a
> prefix longer than a /48.
>

Ok, maybe a little unfair, but still there are plenty of reasons for
subscriber to ask for a prefix longer than a /48.  First, most providers
don't give out /48s.  Second, must subscriber don't need or want more and a
handful of /64s, in most cases a /60 or /56 would more than cover what the
need, if they even know they want more than one /64 anyway.  So, asking for
something you don't really need and know most people won't give you anyway,
doesn't seem very practical or realistic.

As it happens, I personally find none of the architectural reasoning for
> delegating prefixes longer than /48 to retail subscribers at all
> convincing, but please be fair: I’m not disputing that other people here
> make different value judgments than I do about whose interests in the
> architecture of the Internet should be prioritized over the interests of
> everyone else.
>

I'd agree from an architectural perspective, there is no reason for site
prefixes longer than a /48.  However, there isn't an architectural
imperative for /48s either, where as there is an architectural imperative
to give any site that needs or even wants it, including residential sites,
more than one /64.

I think it's far more important to focus on this architectural imperative,
than continually pointing out that architecturally every site can have /48.
Pointing that out really only seems to be frustrating the attempt to
achieve this architectural imperative, not helping it.

Thanks

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Simon Hobson <[email-masked]>
Date: Fri, 14 Apr 2017 21:26:58 +0100

> As a consumer, I really don't like being used as a pawn by vocal people who want to maximize their voice by forcing me to add mine to theirs. I just want the tools that will let me easily use my 2^…

Just playing devils advocate here a bit ....
Isn't that attitude part of the reason that we still talk about the number of ISPs that don't even support IPv6 at all, and "everyone" thinks there's no problem with IPv4 because "NAT fixes everything" ?

Or put another way, if we give people tools to "make do" with a substandard service from their ISP, then there's nothing whatsoever to push delinquent ISPs towards fixing their offerings. And lets face it, with NAT (and especially, carrier grade NAT), there'll be enough IPv4 addresses to go round for ever - so why bother with IPv6 at all ;-)

Yes that's very tongue in cheek. I've lost count of the number of times I've thrown some ramblings on the fundamental brokenness of NAT into various threads when someone's suggested that "NAT is a good thing".

---

From: james woodyatt <[email-masked]>
Date: Fri, 14 Apr 2017 14:01:55 -0700

On Apr 14, 2017, at 12:42, David Farmer <[email-masked]> wrote:
> 
> […] I'd agree from an architectural perspective, there is no reason for site prefixes longer than a /48. […]

Again, not fair. I’m not making any such claim, and I don’t want anyone to be mistaken about it.

The claim I'm making is much more narrow: from an architectural perspective, there is no reason for site prefixes to be *SHORTER* than 48 bits. My claim is that every site from the smallest to the largest can live its entire lifespan without ever renumbering if it is assigned a stable prefix of any length up to 48 bits. Any more than 48 bits and sites run the risk of being forced to renumber when they run out of subnet identifier space, so the most suitable request for them to make is for a stable /48 routing prefix.

The *ONLY* reason to ask for a longer prefix is if the network will grant as short a prefix as the site requests, then charges subscribers progressively more based on the size of their subnet identifier.

I do recognize there are often business reasons for forcing sites to use a smaller subnet identifier number space, i.e. to force them to renumber and pay a premium when they need to move to a routing prefix with larger subnet identifiers. From an architectural perspective, that serves the interests of network owner-operators by the creation of an artificial number scarcity, entirely for business purposes only, where numbers in reality are under monstrous glut conditions so terrible that people should actually be paid for consuming them.

I simply disagree with those who believe that the Internet architecture should serve the interests of service provider network owners over the interests of Internet users. I also recognize this is unlikely ever to be a popular viewpoint in the V6OPS working group.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Apr 2017 09:09:46 +1200

On 15/04/2017 05:55, David Farmer wrote:
...
> delegations of /48, /52, /56, /60, and /64.

Why wouldn't we simply say "MUST support prefix delegation of any
length between /48 and /64"?

Even that is not what the IPv6 routing architecture requires, which
is "MUST support prefix delegation of any length."

   Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 15 Apr 2017 00:04:50 +0200

If it was my personal decision, I’m will more on the side to “force” to always provide /48 to everyone, and I don’t want to start here again the discussion about that. I really think those changes from RFC3177 to RFC6177 did a huge damage to the way the ISPs understood IPv6 and as a consequence, how they are deploying it and in many cases making big mistakes.

However, as editor of RFC7084-bis, I must have a more balanced view …

In the original document the relevant requirement for the WAN-side configuration is:

W-4:  The router MUST act as a requesting router for the purposes of
         DHCPv6 prefix delegation ([RFC3633]).

And this has not been changed in the actual version.

In this document, we are referring to each “relevant” piece of the multiple layers of the cake that makes the “complete cake”, but we aren’t entering in the discussion of changing the “ingredients and their quantities” of each portion of that cake, and I think we should keep it that way.

What I mean here is that if we believe that RFC3633 MUST say something about the length to be supported, then it is RFC3633 which need to be changed on that, not RFC7084-bis. Otherwise, we will be making a set of references to RFCs with lots of exceptions or restrictions to those RFCs, which make them totally different things.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
Organización: University of Auckland
Responder a: <[email-masked]>
Fecha: viernes, 14 de abril de 2017, 23:09
Para: David Farmer <[email-masked]>, james woodyatt <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: [v6ops] Prefix lengths [was: rfc7084-bis and homenet]

    
    
       Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 14 Apr 2017 17:09:53 -0500

> length between /48 and /64"?

Because RFC 6177 recommends nibble alignment for DNS simplicity, but
avoidance of bit math errors is an equally good reason.  If for a consumer
device someone wanted to limit the choices to only those 5 lengths, I'd be
fine with that.  A MUST for any prefix between /48 and /64 wouldn't allow
such simplification for consumers. By explicitly calling out those 5, I'd
hope they would actually get tested too.  Also, I'm trying to limit the
MUSTs to what think I will get deployed in the real world.

In IPv4 there is a natural tendency to organize things based on decimal
digits, in IPv6 there is a similar tendency to organize things that way.
Nibble alignment should make things slightly easier for non-technical
users, and help technical users make fewer mistakes.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Apr 2017 13:23:00 +1200

On 15/04/2017 10:09, David Farmer wrote:
> avoidance of bit math errors is an equally good reason.  

6177 is irrelevant IMNSHO. We're talking about best practice for router
design, and that is surely full support of VLSM/CIDR.

And is it really our job to advise people that binary arithmetic is hard?

> If for a consumer
> fine with that. 

Well, elsewhere on this list there are operators calling for even removing
/64 from our vocabulary. So the more I think about it, the more it seems
to me that there is no reason to exempt a CE router from the most
fundamental router requirement of all: handle any prefix length. Limiting
it to /48.../64 may be practical for now, but in fact it's wrong.

> A MUST for any prefix between /48 and /64 wouldn't allow

I agree, when humans are involved. So I'd prefer to see ISPs following
the 6177 advice. But I don't think it's OK to build that into a hardware

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Apr 2017 13:25:32 +1200

> What I mean here is that if we believe that RFC3633 MUST say something about the length to be supported, then it is RFC3633 which need to be changed on that, not RFC7084-bis. Otherwise, we will be…

Exactly right. A router should never make assumptions about these things.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 15 Apr 2017 11:37:19 +1000

On 15 April 2017 at 08:09, David Farmer <[email-masked]> wrote:
>
> On Fri, Apr 14, 2017 at 4:09 PM, Brian E Carpenter
> <[email-masked]> wrote:
>>
> such simplification for consumers.

The simplification should be that CPE consumers don't have to deal
with prefix lengths at all. We need to both remember and stop
expecting that home users are network nerds or are interested in being
network nerds.

In a residential environment, nobody should ever even see or have to
deal with an IPv6 address. No typing them in, reading them out,
cutting-and-pasting them into devices, or planning and implementing an
addressing structure to number multiple subnets. (It should be
possible do this ... after all, computers can successfully drive cars
on public roads.)

>By explicitly calling out those 5, I'd

MUSTs are minimums, and since developer time costs money, there is a
strong incentive to only implement the minimum. This is particularly
the case with price sensitive low end CPE.

So by saying MUST support /48, /52, /56, /60, and /64, that's all that
will be implemented in CPE, as they'll make the same judgement you
have ("what think I will get deployed in the real world"). That means
it would be best to then prohibit ISPs from providing anything else to
best ensure fault free interoperability.

So the most robust choices are:

- nominate a defined set of prefix lengths, and prohibit ISPs from
providing and CPEs from supporting anything else

- require support for any prefix lengths and don't nominate any specific ones

Asking for both will be worse than choosing one or the other.

Regards,
Mark.

> Nibble alignment should make things slightly easier for non-technical users,
> and help technical users make fewer mistakes.
>
>>

---

From: Simon Hobson <[email-masked]>
Date: Sat, 15 Apr 2017 10:46:03 +0100

Mark Smith <[email-masked]> wrote:

> cutting-and-pasting them into devices, or ...

Checks out of window, no there's no porcine aerial display team practicing above our house :-)

> Asking for both will be worse than choosing one or the other.

Surely the most robust option is to say that CPE routers MUST handle any prefix length, and ISPs SHOULD only issue from a fixed set of lengths - would that latter requirement be better specified in a BCP ? While I'm not a developer, I;d have thought that unless you only support 48 and 64 bit prefix lengths, then supporting any prefix length is no harder than supporting a fixed set that doesn't align on full 16 bit boundaries.
I still have memories of finding that a CPE router from a major brand refused to accept a.b.c.0 as a valid IPv4 address, presumably because they were stuck in "no-one has more than a /24" mentality. I think you are right to assume that if the standards don't say "MUST" for the right things, CPE vendors will do stupid things.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Apr 2017 17:18:32 +0000

Ok, so dumb user question here -- how on earth do I know what I can
request? Do I just ask for a /48, and if that doesn't work, ask for a /64,
and if that does, try for a /56, and if that doesn't work try for a /60?

Nope, calling my ISP and asking isn't a good option, nor is reading the
4-color glossies...

W
On Sat, Apr 15, 2017 at 5:46 AM Simon Hobson <[email-masked]> wrote:

> Surely the most robust option is to say that CPE routers MUST handle any
> prefix length, and ISPs SHOULD only issue from a fixed set of lengths -
> would that latter requirement be better specified in a BCP ? While I'm not
> a developer, I;d have thought that unless you only support 48 and 64 bit
> prefix lengths, then supporting any prefix length is no harder than
> supporting a fixed set that doesn't align on full 16 bit boundaries.
> I still have memories of finding that a CPE router from a major brand
> refused to accept a.b.c.0 as a valid IPv4 address, presumably because they
> were stuck in "no-one has more than a /24" mentality. I think you are right
> to assume that if the standards don't say "MUST" for the right things, CPE
> vendors will do stupid things.
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Apr 2017 13:32:25 -0400

On Apr 15, 2017, at 1:18 PM, Warren Kumari <[email-masked]> wrote:
> Ok, so dumb user question here -- how on earth do I know what I can request? Do I just ask for a /48, and if that doesn't work, ask for a /64, and if that does, try for a /56, and if that doesn't work try for a /60?

You request what you want, the ISP gives you what they are willing to give.   If you send a zero for the prefix length, the ISP will give you whatever their default is.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Apr 2017 19:32:52 +0000

Oh. Cool. Well that seems obvious (now!)

W
On Sat, Apr 15, 2017 at 1:32 PM Ted Lemon <[email-masked]> wrote:

> You request what you want, the ISP gives you what they are willing to
> give.   If you send a zero for the prefix length, the ISP will give you
> whatever their default is.
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Apr 2017 08:22:10 +1200

Ted,

> You request what you want, the ISP gives you what they are willing to give.   If you send a zero for the prefix length, the ISP will give you whatever their default is.

I assume you are referring to a specific protocol there. Which one? PD? RADIUS? Both?

There's nothing to say this is the only mechanism. (OK, I have skin in the game: draft-ietf-anima-prefix-management. Domestic CE is not its intended market, however.) But in any case, it's clear to me that the only future-proof rule is that the CE MUST support any prefix length that the ISP chooses to offer. That won't get us away from only supporting /64 subnets, but that's elsewhere in the spec.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Apr 2017 16:23:06 -0400

> I assume you are referring to a specific protocol there. Which one? PD? RADIUS? Both?

Prefix delegation.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Apr 2017 08:36:09 +1200

On 15/04/2017 21:46, Simon Hobson wrote:
> Surely the most robust option is to say that CPE routers MUST handle any prefix length, 

+1

> and ISPs SHOULD only issue from a fixed set of lengths - would that latter requirement be better specified in a BCP? While I'm not a developer, I;d have thought that unless you only support 48 and 64 bit prefix lengths, then supporting any prefix length is no harder than supporting a fixed set that doesn't align on full 16 bit boundaries.

The only real argument for a defined set of lengths, as mentioned in RFC6177, is to choose nibble boundaries: 
"- the operational considerations of managing and delegating the
   reverse DNS tree under ip6.arpa on nibble versus non-nibble
   boundaries should be given adequate consideration."
So yes, IMHO there's a case for saying that for SOHO customers, an ISP MAY delegate one of {/48,/52,/56,/60} and SHOULD NOT delegate /64}

  Brian

> .

---

From: Simon Hobson <[email-masked]>
Date: Sun, 16 Apr 2017 08:12:17 +0100

> You request what you want, the ISP gives you what they are willing to give.   If you send a zero for the prefix length, the ISP will give you whatever their default is.

Or in the real world (with some ISPs), you ask for what you want, they reply back "sorry, don't do that" when the sales person (who wouldn't know their IPv6 from their SMTP) finds there isn't a matching tick box on their screen. So you have to go back and forth a few times until you guess the right number.

Yes, I'm a bit cynical having dealt (on behalf of clients) with a number of ISPs through work and the varying "quality" of their support arrangements - many ISPs appear to be managed by marketing people with little idea of what they are managing. So far I haven't come across one making you upgrade to a business connection (at a higher price) in order to get IPv6 !

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Apr 2017 09:39:26 +0900

On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter <
[email-masked]> wrote:

> > and ISPs SHOULD only issue from a fixed set of lengths

Assigning prefixes on nibble boundaries consumes between 2 and 8 times the
address space. I don't think it's a good idea to go out of our way to say
that ISPs should only provide certain lengths just because they're easier
for users to understand.

We can certainly say that if an ISP wants to delegate reverse DNS then the
only way to do that is to align on a nibble boundary. But if most ISPs
don't do that anyway, there's no point saying they need to change prefix
lengths to do it.

---

From: james woodyatt <[email-masked]>
Date: Mon, 17 Apr 2017 08:36:09 -0700

> You request what you want, the ISP gives you what they are willing to give.   If you send a zero for the prefix length, the ISP will give you whatever their default is.

Except, nope… if you request zero, some ISPs give you no prefix (despite that being wrong). So you request /48, and you get what they send. And the day ISPs start charging you more for requesting a /48 and getting a /56 vs. requesting a /60 and getting a /60 is the day a whole bunch of CPE routers have to be updated.

Because of course this is how the architecture is supposed to work. Why do you ask?

---

From: Simon Hobson <[email-masked]>
Date: Mon, 17 Apr 2017 18:10:41 +0100

Lorenzo Colitti <[email-masked]> wrote:

> Assigning prefixes on nibble boundaries consumes between 2 and 8 times the address space. I don't think it's a good idea to go out of our way to say that ISPs should only provide certain lengths just because they're easier for users to understand.

Except that AIUI no ISP gets any allocation smaller than a /32, and if they were to give out a /56 to every customer, then they could support up to 16 million customers. In the UK, AIUI there are only something like 30 million homes, and there are "quite a few" ISPs.
Make that a /60 (still on a nibble boundary, gives the user up to 16 networks to play with) then that goes up to supporting 256 million customers - so several times more than the total number of connections in the UK even if there were only one ISP.

> We can certainly say that if an ISP wants to delegate reverse DNS then the only way to do that is to align on a nibble boundary. But if most ISPs don't do that anyway, there's no point saying they need to change prefix lengths to do it.

Realistically, every ISP needs to support delegation of the IPv6 reverse address space IF the customer wants it. No way do I want the hassle of maintaining an ISPs delegation via some form of portal designed by someone who demonstrates that they've never managed any network services (that's what some portals shout out).
Even worse, I don't want to have to do the "email some service team and they'll update it 'sometime'"

---

From: Ola Thoresen <[email-masked]>
Date: Mon, 17 Apr 2017 20:52:35 +0200

On 17. april 2017 02:39, Lorenzo Colitti wrote:

> On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Assigning prefixes on nibble boundaries consumes between 2 and 8 times 
> the address space. I don't think it's a good idea to go out of our way 
> to say that ISPs should only provide certain lengths just because 
> they're easier for users to understand.
>

Except that "easier for users to understand" IS an important thing. The 
routers and hosts can handle whatever we throw at them.  But when I need 
to debug a network problem, the ability to easily read and understand 
all firewall-policies and routing entries and instantly recognize that a 
certain address belongs to a certain prefix which is assigned to a 
specific interface with a set of policies added to it, is of huge 
importance.

Not keeping it within a nibble makes that job a LOT harder.  And more 
error prone, which leads to all sorts of issues, both for the user in 
question, and also possibly for other users.

I can't see any reason for an ISP to assign anything less than a /60, 
even to grandma and her cat.  Worrying about wasting addresses, so you 
only give her one or two /64s is just silly, as Simon pointed out already.
And if 16 subnets are not enough, even 256 or 4096 is not going to be a 
real world problem for the next 1000 generations.  At least in the 
RIPE-region, any ISP will get a /29 without much of a problem.

So making the network harder for the end users to maintain just to save 
some prefixes is pretty stupid.  The only reason some ISPs do this is 
because they are still stuck in their IPv4 mindset where each address is 
an asset.  And I think we should try to help the ISPs get out of that 
mindset.
Making it clear that they should only assign prefixes on the nibble 
boundaries, and never EVER assign a single /64 is a way to force them to 
rethink their policies.

/Ola (T)

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Apr 2017 12:30:12 -0700

No hats.

I'm not sure I disagree with anything you said. That said, I would far rather see a statement like this come from a *NOG in a BCOP than from the IETF. Reason: there is no *architectural* reason that an IPv6 prefix couldn't be any length one chooses; the reasons for given lengths have to do with user experience, support, and so on. 

My two yen.

> On Apr 17, 2017, at 11:52 AM, Ola Thoresen <[email-masked]> wrote:
> 
>> On Sun, Apr 16, 2017 at 5:36 AM, Brian E Carpenter <[email-masked]> wrote:
> Except that "easier for users to understand" IS an important thing.  The routers and hosts can handle whatever we throw at them.  But when I need to debug a network problem, the ability to easily read and understand all firewall-policies and routing entries and instantly recognize that a certain address belongs to a certain prefix which is assigned to a specific interface with a set of policies added to it, is of huge importance.
> 
> Not keeping it within a nibble makes that job a LOT harder.  And more error prone, which leads to all sorts of issues, both for the user in question, and also possibly for other users.
> 
> I can't see any reason for an ISP to assign anything less than a /60, even to grandma and her cat.  Worrying about wasting addresses, so you only give her one or two /64s is just silly, as Simon pointed out already.
> And if 16 subnets are not enough, even 256 or 4096 is not going to be a real world problem for the next 1000 generations.  At least in     the RIPE-region, any ISP will get a /29 without much of a problem.
> 
> So making the network harder for the end users to maintain just to save some prefixes is pretty stupid.  The only reason some ISPs do this is because they are still stuck in their IPv4 mindset where each address is an asset.  And I think we should try to help the ISPs get out of that mindset. 
> Making it clear that they should only assign prefixes on the nibble boundaries, and never EVER assign a single /64 is a way to force them to rethink their policies.  
> 
> /Ola (T)
> 
> 
>

---

From: Sander Steffann <[email-masked]>
Date: Mon, 17 Apr 2017 22:50:06 +0200

Hi Fred,

> Op 17 apr. 2017, om 21:30 heeft Fred Baker <[email-masked]> het volgende geschreven:
> 
> No hats.
> 
> I'm not sure I disagree with anything you said. That said, I would far rather see a statement like this come from a *NOG in a BCOP than from the IETF.

You mean something like this: https://www.ripe.net/ripe/mail/archives/bcop/2017-March/000159.html? ;-)

> Jan Zorz - Go6 jan at go6.si
> Mon Mar 27 15:30:58 CEST 2017
> Dear RIPE BCOP community,
> 
> As promised at last RIPE meeting in Madrid, we produced a first draft of
> "Best Current Operational Practice for operators: IPv6 prefix assignment
> for end-users - static (stable) or dynamic (non-stable) and what size to
> choose."
> 
> [...]

Cheers,
Sander

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Apr 2017 14:25:02 -0700

> On Apr 17, 2017, at 1:50 PM, Sander Steffann <[email-masked]> wrote:
> 
> Hi Fred,
> 

Something like that, yes. I'll note that this is a random document sent to an email list, advertised as a "first draft". I'd prefer something the community had agreed to. That said, "yeah, something like that."

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 17 Apr 2017 23:28:49 +0200

Hopefully we will have a new version published ahead the next RIPE meeting, and agreed by then ;-)

Regards,
Jordi

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Apr 2017 10:09:56 +1000

> don't do that anyway, there's no point saying they need to change prefix

This is despite the fact that it would be possible to automatically
delegate the reverse zones quite easily.  Or that people do actually
setup reverse zones in the home because they want address to name
mappings.

Human factors are just as important as any other factor when designing
how to run networks.  ISP's should give everyone a /48.  It saves
money in the long run and there are enough to go around.  It allow
the site to hand out /64's as needed internally.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Apr 2017 18:45:03 -0700

> I'm not sure I disagree with anything you said. That said, I would far rather see a statement like this come from a *NOG in a BCOP than from the IETF. Reason: there is no *architectural* reason tha…
There are quite a few asics over the years where implmentors have looked
at the ietf ipv6 architecture; then produced optimizations that leverage
it. The upshot therefore is that naively running roughshod over them can
and does produce unexpected results. It's not unreasonable to expect
that if expectations change that it'll be a few years before there's a
congruence between what you expect and what happens.

It's easy enough for example to store any entry for a /128 /127 /126 and
all point to point link addresses in the exact match table. not so with
/112s or /96s. You may not  in general like your hardware capabilties
when it comes to storing < /64 prefixes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 18 Apr 2017 11:42:11 +0900

On Tue, Apr 18, 2017 at 9:09 AM, Mark Andrews <[email-masked]> wrote:

> delegate the reverse zones quite easily.

And why don't they delegate reverse zones automatically?

I'm pretty sure the reason is *not* "we'd be happy to delegate a reverse
zone to you, but unfortunately we can't do that because we only gave you a
/61 and that's not on a nibble boundary".

If that's not the reason, then there's no point writing text to remove that
reason.

---

From: [email-masked]
Date: Tue, 18 Apr 2017 08:58:46 +0200

> You request what you want, the ISP gives you what they are willing to give.   If you send a zero for the prefix length, the ISP will give you whatever their default is.

"you" being the IPv6 CE router. There is really very little way that CE can know what to request for. Perhaps it could deduce something from HNCP, but this deployment model is very unlikely. I think this idea that CE's are going to request what they need and ISP's are going to adhere to that request seems very far fetched.

This is an out-of-band negotiation often involving money. In RFC3633 this is purely a hint and the ISP is certainly not expected to adhere to it, nor is the client expected to set it with very much confidence.

Ole

---

From: Erik Kline <[email-masked]>
Date: Tue, 18 Apr 2017 16:02:38 +0900

On 18 April 2017 at 15:58, <[email-masked]> wrote:

> "you" being the IPv6 CE router. There is really very little way that CE
> can know what to request for. Perhaps it could deduce something from HNCP,
> but this deployment model is very unlikely. I think this idea that CE's are
> going to request what they need and ISP's are going to adhere to that
> request seems very far fetched.
>
> This is an out-of-band negotiation often involving money. In RFC3633 this
> is purely a hint and the ISP is certainly not expected to adhere to it, nor
> is the client expected to set it with very much confidence.
>

Certainly my assumption was always that we'd devolved to CPEs requesting a
/48 and ISPs doing...whatever they want.

---

From: <[email-masked]>
Date: Tue, 18 Apr 2017 07:36:07 +0000

Hi Brian, 

I don't think we need to mandate any prefix length. I like the current wording of WPD-2 and WPD-3 because it does not impose any "hint" value. 

We need to avoid CE routers making assumptions on the prefix length. It may be appropriate to add an item so that CE routers comply with BCP198. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Brian E Carpenter
> Envoyé : vendredi 14 avril 2017 23:10
> À : David Farmer; james woodyatt
> Cc : [email-masked]
> Objet : [v6ops] Prefix lengths [was: rfc7084-bis and homenet]
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 18 Apr 2017 19:43:12 +0900

On Tue, Apr 18, 2017 at 4:36 PM, <[email-masked]> wrote:

> We need to avoid CE routers making assumptions on the prefix length. It
> may be appropriate to add an item so that CE routers comply with BCP198.
>

BCP198 talks about forwarding, not address assignment. It's still the case
that the address block assigned to a CPE must be a /64 or shorter.

---

From: Simon Hobson <[email-masked]>
Date: Tue, 18 Apr 2017 12:01:56 +0100

Lorenzo Colitti <[email-masked]> wrote:

> I'm pretty sure the reason is *not* "we'd be happy to delegate a reverse zone to you, but unfortunately we can't do that because we only gave you a /61 and that's not on a nibble boundary".

No, it won't be at the moment ...

> If that's not the reason, then there's no point writing text to remove that reason.

I disagree. Just because there are other reasons, doesn't negate it being a good idea to nip this one in the bud before it does become an issue. Better to be clear up front so bad implementations can be called out for being "wrong"*, rather than telling people after the fact that "we've just change the rules, what you implemented and was allowed under the old rules is now wrong* under the new rules". Or put another way, better to make it clear up front what "right" is, than try and change things after they have been implemented.

* However you define "wrong" - against the RFCs, against a best practice document, whatever.

Bear in mind that ISPs are mostly still getting to grips with a whole change in manglement mindset about IPv6 - that much is clear from the  discussions about prefix lengths and how some ISPs are still treating addresses as "scarce" like they do with IPv4. Given that it's now uncommon to get as much as a /24 in address space, delegating reverse DNS will be unfamiliar to most ISPs, and for those that do do it, it'll almost certainly be a manual process - quite justifiable when a /24 only comes with an expensive business service, and probably only taken up by those with network management skills.

As it happens, I manage delegated reverse DNS for a /24 and a /23 at work.

So I wouldn't put much store on what ISPs are or aren't doing right now with IPv6 reverse DNS delegation - it's probably down the list, well below "getting an IPv6 service that works". Just as the population at large still aren't asking for IPv6, fewer still will be asking for reverse DNS delegation - so the "when people start asking for it ..." argument applies.

---

From: <[email-masked]>
Date: Tue, 18 Apr 2017 11:09:10 +0000

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : mardi 18 avril 2017 12:43
À : BOUCADAIR Mohamed IMT/OLN
Cc : Brian E Carpenter; [email-masked]
Objet : Re: [v6ops] Prefix lengths [was: rfc7084-bis and homenet]

On Tue, Apr 18, 2017 at 4:36 PM, <[email-masked]<mailto:[email-masked]>> wrote:
We need to avoid CE routers making assumptions on the prefix length. It may be appropriate to add an item so that CE routers comply with BCP198.

BCP198 talks about forwarding, not address assignment.
[Med] I know what that RFC is about. Prefix length is not only related to assignment but also to other matters such as forwarding, hence my proposal to add an item for BCP198.

It's still the case that the address block assigned to a CPE must be a /64 or shorter.
[Med] There is already BCP 157 for this. WPD-2 and WPD-3 cited in my initial message are IMHO consistent with that BCP.

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Apr 2017 12:32:10 -0700

On Apr 18, 2017, at 4:01 AM, Simon Hobson <[email-masked]> wrote:
> Bear in mind that ISPs are mostly still getting to grips with a whole change in manglement mindset about IPv6 - that much is clear from the  discussions about prefix lengths and how some ISPs are still treating addresses as "scarce" like they do with IPv4.

Again, no hats.

I have had an idea, which I'd like to validate or have invalidated, that a primary reason people don't implement reverse DNS in IPv6 is that they're not sure how. In IPv4, it has been pretty straightforward: either they have names for all of the addresses they would respond to, or they implement one for the prefix that has a default name for any addresses they didn't have names for, or maybe they figure out how to create a name for the unused addresses - they are able to implement it as a (potentially large) database of individual names. In IPv6, almost all addresses (if I have 1000 IIDs in a /64, I still have 18,446,744,073,709,550,616 addresses) fall into the default category, and as a result they need a layered strategy - they look up the actual address, and it that fails, back off to a name-per-prefix. 

If they don't see people asking for it, they don't see much impetus to implement anything.

In separate news, I asked someone who might know about email use of IPv6. The statement I got back (which I'm not allowed to quote or attribute) said that they weren't sure of their methodology, but if it was correct, a vanishingly small subset of emails use it. In that, I wonder about chickens and eggs. If information security policy requires reverse DNS validation (which in IPv4 it usually does) and there is no way to do it, does that mean that the sender chooses to use IPv4? Or is it the other way around - that folks prefer IPv4, perhaps because their mail systems do, or their mail systems are not yet IPv6-capable or on IPv6 networks? I know when CERNET started mailing lists for SAVI discussion, the servers were IPv6-only, and that didn't work so well.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 18 Apr 2017 13:18:15 -0700

At Tue, 18 Apr 2017 08:58:46 +0200,
[email-masked] wrote:

> "you" being the IPv6 CE router. There is really very little way that
> CE can know what to request for. Perhaps it could deduce something
> from HNCP, but this deployment model is very unlikely. I think this
> idea that CE's are going to request what they need and ISP's are
> going to adhere to that request seems very far fetched.
>
> This is an out-of-band negotiation often involving money. In RFC3633
> this is purely a hint and the ISP is certainly not expected to
> adhere to it, nor is the client expected to set it with very much
> confidence.

FWIW, this is basically what I thought when I raised a question on the
practicality of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue:
https://www.ietf.org/mail-archive/web/dhcwg/current/msg17360.html
but at that time I was told that there is a real need for the
smartness of the CE router (i.e. PD client) side.  I don't remember I
heard specifically what it is, though.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2017 10:50:44 +1200

> /48 and ISPs doing...whatever they want.

That might be a reasonable default behaviour, but if the ISP responds with a
/49, we need to be clear that the CPE MUST be capable of handling it.

   Brian

---

From: Nicolas Antoniello <[email-masked]>
Date: Tue, 18 Apr 2017 18:04:40 -0500

Just to do some philosophy here: why should any ISP give as much as a /4x
(with x = whatever) while there is almost no domestic CPE that even if they
can handle that /4x delegation they do not give the "common" user the
possibility to divide or decide anything about the subnetting of her/his
networks... with this I mean if we possible have to make an effort in
telling the CPEs industry that they have to start thinking in equipments
and interfaces that make that process of deciding about my own network a
funny and easy task? (may be this should be enforced in some or though some
BCPs or RFCs).

Regards,
Nicolas

On Tue, Apr 18, 2017 at 5:50 PM, Brian E Carpenter <
[email-masked]> wrote:

> this

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Apr 2017 09:06:25 +1000

In message <[email-masked]>, Fred Baker writes:
> > Bear in mind that ISPs are mostly still getting to grips with a whole chang
> e in manglement mindset about IPv6 - that much is clear from the  discussions
>  about prefix lengths and how some ISPs are still treating addresses as "scar
> ce" like they do with IPv4.
> 
> Again, no hats.
> 
> I have had an idea, which I'd like to validate or have invalidated, that a pr
> imary reason people don't implement reverse DNS in IPv6 is that they're not s
> ure how. In IPv4, it has been pretty straightforward: either they have names 
> for all of the addresses they would respond to, or they implement one for the
>  prefix that has a default name for any addresses they didn't have names for,
>  or maybe they figure out how to create a name for the unused addresses - the
> y are able to implement it as a (potentially large) database of individual na
> mes. In IPv6, almost all addresses (if I have 1000 IIDs in a /64, I still hav
> e 18,446,744,073,709,550,616 addresses) fall into the default category, and a
> s a result they need a layered strategy - they look up the actual address, an
> d it that fails, back off to a name-per-prefix. 
> 
> In separate news, I asked someone who might know about email use of IPv6. The
>  statement I got back (which I'm not allowed to quote or attribute) said that
>  they weren't sure of their methodology, but if it was correct, a vanishingly
>  small subset of emails use it. In that, I wonder about chickens and eggs. If
>  information security policy requires reverse DNS validation (which in IPv4 i
> t usually does) and there is no way to do it, does that mean that the sender 
> chooses to use IPv4? Or is it the other way around - that folks prefer IPv4, 
> perhaps because their mail systems do, or their mail systems are not yet IPv6
> -capable or on IPv6 networks? I know when CERNET started mailing lists for SA
> VI discussion, the servers were IPv6-only, and that didn't work so well.

Well I never got any traction with
https://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-02 but
it show how easy it could be to automatically delegate reverse zones
along with the prefix delegation.

Reading through I saw a minor typo (s/DNS KEY/DNSKEY/).

DHCP servers update DNS servers all the time.

Adding PTR records is just as easy but you use TCP as the initial
authenticator.  There already exists nameservers and DNS UPDATE
clients that are capable of doing this part.  named supports
"tcp-self" as a update policy method which looks at the IP address
of the TCP connection the UPDATE message is sent over and computes
the reverse name and if the update is updating that name it is
allowed.  We wrote the code to support this over a decade ago now.

nsupdate -v
local <address>
del <reverse-of-address> PTR
add <reverse-of-address> 3600 IN PTR <node-name>
send

-v: use TCP
local: sets the source address
del: clean out any existing PTR records
add: add the new PTR record
send: figure out where to send the UPDATE message by looking for the
      SOA record of the containing zone then send the UPDATE over TCP

Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Apr 2017 09:35:50 +1000

In message <CADHEbK9P4vMf=[email-masked]>
> funny and easy task? (may be this should be enforced in some or though some

I already have 3 /64s connected to my CPE router.  One for the wired
net, one for the 5G WiFi and one for the 2G WiFi.  If I had a second
router it can request the /64's it needs for its downstream interfaces
from the CPE router.  I don't need to do a address plan.  The CPE
works it out.  When a second router is connected, it too will work
it out based on the prefixes it gets from the CPE router.  Or when
I add a virtual network and router on one of the machines for
testing.

Yes, there will end up being lots of /64 routes installed.  That
really doesn't matter however as the hardware is more than capable
of handling it.

My IPv6 ISP (HE) gives me a /48.  I can do all this because they
are not stingy.

You needed a address plan with IPv4 because there were not enough
addresses to go around so you had to size each subnet differently.

With IPv6 you just give each subnet a /64 and let the routing sort
out how to deliver the packets.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2017 15:10:44 +1200

>> funny and easy task? (may be this should be enforced in some or though some

In addition to what Mark says below, we have HNCP now. We should plan
for a future where SOHO networks contain a large number of subnets, with all
addressing and routing being automated. So we certainly need the CE router
to support this, and ISPs will slowly come to understand their new market.
IMHO, our job is to write specs that nudge vendors in the right direction.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Apr 2017 19:49:48 +0200

Le 19/04/2017 à 01:35, Mark Andrews a écrit :
> > In message > 
<CADHEbK9P4vMf=[email-masked]> > , 
Nicolas Antoniello writes: >> >> Just to do some philosophy here: why 
should any ISP give as much >> as a /4x (with x = whatever) while there 
is almost no domestic CPE >> that even if they can handle that /4x 
delegation they do not give >> the "common" user the possibility to 
divide or decide anything >> about the subnetting of her/his networks... 
with this I mean if we >> possible have to make an effort in telling the 
CPEs industry that >> they have to start thinking in equipments and 
interfaces that make >> that process of deciding about my own network a 
funny and easy >> task? (may be this should be enforced in some or 
though some BCPs >> or RFCs). >> >> Regards, Nicolas > > I already have 
3 /64s connected to my CPE router.

I have 8 such /64s :-)

My DSL operator "free" 'delegates' my DSL box a fixed /56 and provides 
me a GUI, shown below, to manually configure 8 /64 routes towards the 
IPv6 address of in-home routers.

It is great that I can have many /64s in-home.

But I dont like that I have to manually configure these route entries, 
even though it's a GUI.

And I dont like that there is no freedom in deciding maybe a /63 towards 
an IP (GUI form hardcodes '/64').

> One for the wired net, one for the 5G WiFi and one for the 2G WiFi. > If I had a second router it can request the /64's it needs for its > 
downstream interfaces from the CPE router.  I don't need to do a > 
address plan.  The CPE works it out.  When a second router is > 
connected, it too will work it out based on the prefixes it gets > from 
the CPE router.  Or when I add a virtual network and router on > one of 
the machines for testing. > > Yes, there will end up being lots of /64 
routes installed.  That > really doesn't matter however as the hardware 
is more than capable > of handling it. > > My IPv6 ISP (HE) gives me a 
/48.  I can do all this because they are > not stingy. > > You needed a 
address plan with IPv4 because there were not enough > addresses to go 
around so you had to size each subnet differently. > > With IPv6 you 
just give each subnet a /64 and let the routing sort > out how to 
deliver the packets.

I read it, and disagree with some parts.

Alex

> > Mark >

---

From: Simon Hobson <[email-masked]>
Date: Fri, 21 Apr 2017 19:56:36 +0100

Alexandre Petrescu <[email-masked]> wrote:

> My DSL operator "free" 'delegates' my DSL box a fixed /56 and provides me a GUI, shown below, to manually configure 8 /64 routes towards the IPv6 address of in-home routers.
> 
> But I dont like that I have to manually configure these route entries, even though it's a GUI.
> 
> And I dont like that there is no freedom in deciding maybe a /63 towards an IP (GUI form hardcodes '/64').

If you don't define any routes, do they just route the whole /56 to your router, or do they not route anything ? If they route the whole /56 then you can do what you like on your own router.

But down't forget that if you route two adjacent /64s to one router, on the other side you can combine them into a /63 (with the proviso that they /64s are both from the same /63). Upstream, addresses are just addresses and the routers have no knowledge of whether any particular address is part of a /64 or a /63.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 24 Apr 2017 13:24:23 +0200

Le 21/04/2017 à 20:56, Simon Hobson a écrit :
>> My DSL operator "free" 'delegates' my DSL box a fixed /56 and
>> provides me a GUI, shown below, to manually configure 8 /64 routes
>> towards the IPv6 address of in-home routers.
>>
>> And I dont like that there is no freedom in deciding maybe a /63
>> towards an IP (GUI form hardcodes '/64').
>
> If you don't define any routes, do they just route the whole /56 to
> your router, or do they not route anything ? If they route the whole
> /56 then you can do what you like on your own router.

They route the whole /56 to my DSL box.  I think they route so somehow
with IPv4 tunneling, or maybe what is called '6rd'.  There is no option
to stop IPv4 (whereas IPv6 is optional).

> But down't forget that if you route two adjacent /64s to one router,
> on the other side you can combine them into a /63 (with the proviso
> that they /64s are both from the same /63). Upstream, addresses are
> just addresses and the routers have no knowledge of whether any
> particular address is part of a /64 or a /63.

Ah, that  is right - it is possible to route two adjacent /64s to one
router and then combine them there into one /63.

Alex