Subject: [v6ops] FW: Can you please review and comment on draft-xiao-v6ops-nd-deployment-guidelines

From: Xipengxiao <[email-masked]>
Date: Sat, 23 Oct 2021 19:26:12 +0000

Hi folks,

With Brian's permission, I publish his review and our discussion here.  Your comments are welcome.  Thanks.  XiPeng 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, October 20, 2021 12:48 AM
> To: Xipengxiao <[email-masked]>
> Cc: Sheng Jiang <[email-masked]>
> Subject: Re: Can you please review and comment on draft-xiao-v6ops-nd- 
> deployment-guidelines
> 
> Hi XiPeng,
> 
> I do not really have the expertise for a deep review, but the work 
> looks very complete.
> 
> However, I do have some concerns about moving away from a traditional 
> deployment, despite the known problems. Obviously, very big WiFi 
> networks are a bad idea, but in my experience small ones (and small 
> Ethernet segments) work well. In particular there are two issues:
> 
> 1. Multicast is needed in many case, for mDNS in particular 
> (especially if DNS- SD becomes a success). So isolation is a problem 
> unless that requirement is satisfied. A correct implementation of MLD works well, from my experience.
> (There are also incorrect implementations, unfortunately.)

[XX] I agree that multicast is needed in some places.  But in those places network admin's can choose not to apply host isolation and use traditional ND.  Section 3.2 step 4 clearly states this.

There are scenarios where multicast is undesirable.  In those cases, network admin's can apply host isolation.  Because this draft does not dictate a single solution, and allow people to choose different solutions based on different scenarios, I think it's useful.

> 2. I expect a lot of objections to UPPH. It really is a ridiculous 
> waste of address space, unless we can reduce the subnet size with a 
> prefix greater than /64, and that seems very difficult in the IETF.

[XX] While I acknowledge that giving each host a /64 may seem wasteful, in reality it may not be so bad, for 2 reasons (1) I heard that RIR will give /29 to an applicant without requiring special justification. This will provide 2**35=32 billion /64's - more than enough I would think (2) We are giving a /64 to each mobile phone.  If we can afford that in this scenario (with by far the largest number of hosts), we should be able to afford that in other scenarios (with smaller number of hosts).  Do you agree?

Thank you very much again for your review.  

XiPeng

---

From: Gert Doering <[email-masked]>
Date: Sun, 24 Oct 2021 10:07:49 +0200

Hi,

On Sat, Oct 23, 2021 at 07:26:12PM +0000, Xipengxiao wrote:
> [XX] While I acknowledge that giving each host a /64 may seem wasteful, 
> in reality it may not be so bad, for 2 reasons (1) I heard that RIR will 
> give /29 to an applicant without requiring special justification. This 
> will provide 2**35=32 billion /64's - more than enough I would think 

The /29 is intended to number many individual customers.  ISPs are giving
/56s out of this to "SOHO" customers, and /48s to "business customers".

You can't assume that these are all free to be burned in arbitrary numbers 
of /64s on wifi deployments.

(I, for one, will never ever deploy technology that will require me
to allocate something like a /54 to a wifi network, just to be able
to serve 1000 mobile clients [/54 = 2^10 = 1024 /64s] - which is not 
even very large for a corp wifi)

> (2) We are giving a /64 to each mobile phone.  If we can afford
> that in this scenario (with by far the largest number of hosts),
> we should be able to afford that in other scenarios (with smaller
> number of hosts).  Do you agree?

This is totally not comparable, as there are many layers of address
not involved here.  Mobile ISPs get the /29 "all for themselves",
and the way stuff attaches to the mobile network is way different
from the way wifi segments are attached to normal building networks.

(I like the idea of being able to delegate a /96 with DHCPv6-PD to
each device, to appease Lorenzo and finally be done with the everlasting
DHCPv6 vs. Android discussion - but the numbers for /64 are really
not working out)

Gert Doering
        -- with some experience in address space & vs. aggregation math
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
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: Xipengxiao <[email-masked]>
Date: Sun, 24 Oct 2021 16:04:03 +0000

Hi Gert,

Thank you for your time to review and comment.  Please see my response in line.

> From: Gert Doering [mailto:[email-masked]]
> Sent: Sunday, October 24, 2021 10:08 AM
> Cc: [email-masked]; [email-masked]
> Subject: Re: [v6ops] FW: Can you please review and comment on draft-xiao-
> v6ops-nd-deployment-guidelines
> 
> Hi,
> 
> > [XX] While I acknowledge that giving each host a /64 may seem
> > wasteful, in reality it may not be so bad, for 2 reasons (1) I heard
> > that RIR will give /29 to an applicant without requiring special
> > justification. This will provide 2**35=32 billion /64's - more than
> > enough I would think
> 
> The /29 is intended to number many individual customers.  ISPs are giving /56s
> out of this to "SOHO" customers, and /48s to "business customers".
 
[XX] A business Wi-Fi deployment can be considered as a " business customer", and be given a /48 as you suggest. This will allow 64K hosts if each host gets a /64.  Seems like a reasonable arrangement to me.

> You can't assume that these are all free to be burned in arbitrary numbers of
> /64s on wifi deployments.
> 
> (I, for one, will never ever deploy technology that will require me to allocate
> something like a /54 to a wifi network, just to be able to serve 1000 mobile
> clients [/54 = 2^10 = 1024 /64s] - which is not even very large for a corp wifi)
 
[XX] Your opinion is respected.  But the fact is we give each mobile phone is /64 today, and each RG (resident gateway) a /56.  So giving a host a /64 is already a widely existed current practice.   

> > (2) We are giving a /64 to each mobile phone.  If we can afford that
> > in this scenario (with by far the largest number of hosts), we should
> > be able to afford that in other scenarios (with smaller number of
> > hosts).  Do you agree?
> 
> This is totally not comparable, as there are many layers of address not involved
> here.  Mobile ISPs get the /29 "all for themselves", and the way stuff attaches
> to the mobile network is way different from the way wifi segments are
> attached to normal building networks.
 
[XX] First our draft is not specific to Wi-Fi.  Second, why giving a host a /64 or not depends on " the way stuff attaches
to the network"?

> 
> (I like the idea of being able to delegate a /96 with DHCPv6-PD to each device,
> to appease Lorenzo and finally be done with the everlasting
> DHCPv6 vs. Android discussion - but the numbers for /64 are really not working
> out)

[XX] I have no problem with what you suggested, but that's a different discussion.  Please note that our draft didn't prescribe any new solution (or advocate giving each host a /64).  All it did was reviewing the existing ND issues and solutions, and suggested how to select a solution based on the deployment scenario.

Thanks again for your time.  It's appreciated!

XiPeng

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Oct 2021 08:29:14 +1300

> But the fact is we give each mobile phone is /64 today, and each RG (resident gateway) a /56.  So giving a host a /64 is already a widely existed current practice.   

Note that if a mobile device (maybe not a phone!) is acting as a local hotspot, it needs a prefix, not an address, and /64 is the longest prefix that respects the current addressing architecture. Even that does not allow subnetting.

Regards
    Brian Carpenter
    Thinking of the IETF standards process: https://xkcd.com/2530/

On 25-Oct-21 05:04, Xipengxiao wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>