Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

[Wuyts Carl <[e-mail]>]

Well, seems like my comments are being taken the "wrong" way.

To come back on Barbara's comments:
""

<bhs> The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered).

[Carl] I agree

When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used.

[Carl] I agree

Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do.

[Carl But I do not agree on this one. You want a "user configuration" that either does SLAAC, DHCP_IA_NA or unnumbered.  In your opinion, this must be done from a single configuration (no end-user interference, so from "factory defaults").  So, the CPE must either able to "sense" the configuration or just request all of the possible things ??  Sorry, but not a good idea.  So, how must the CPE "sense" this and request the appropriate configuration ?  Listen to RA ?  Fine, although you would run into problems when, on a certain link (just say e.g. PPP), nothing would be received, what would you do with that ?  No RA received, so ask IA_NA ?  Fine again, but what if the DHCPv6 server does not provide anything ?  Then you'd swap to "unnumbered" ?  What interface are you going to use to put an address from ia_pd onto ?  Play "safe" and put it on Lan interface (just to avoid issues if ia_pd = 64) ?

This maybe sounds ok for you, but in fact it's not.  Suppose the CPE has been configured with all of the above, you might end with both putting an address from ia_pd on top of an interface (no matter lan or virtual), which is ok for me, but what if you end up in a situation, where the DHCPv6 server does not return anything unless you ask for a specific set of DHCPv6 options and if not, no info would be sent ?  In that case, you're CPE ends up with ... no configuration at all, only link local addresses.  What if your access network would support SLAAC, so you get a prefix on the WAN intf trough SLAAC, but at the same time, you're also asking IA_NA, so might get that one too + you put a prefix from ia_pa too ?  It can still work, but not sure this would be the best idea though.

So no matter how much more things you're adding for the CPE, you will never have a 100% coverage.



If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204.
""
And on the one of "virtual intfs":
I can of course only agree that CPE vendors are perfectly capable of deciding for the appropriate intf to put an address from ia_pa on top off, however, if your req in RFC6204 uses "virtual interface" then  I'd say your req can never be met in case of ia_pd length = 64.  If you want to keep using this exact phrasing, then it is wrong.  So, if you know state it does not matter what terminology is being used, then I'm wondering why RFcs keep bothering to use lan, wan virtual, ... ???

On the comments from Ray on usage of /64 ia_pd length:
I can only say it is allowed.  I don't say it is a good idea, I don't say we recommend it, but it's being used in the real world, so we're facing it from day to day (again, it's residential market, and we have to cope with those too, as after all, it is valid to use /64).  And although you might consider this to be a "corner case", which I don't think is really the case, then I would imagine it should still be possible to use the RFC, no ?  If not, a statement must be added to the RFC that this is only to be applied if your CPE is using ia_pd lengths of < 64, which goes in against the basic IPv6 RFCs I'd say.

Regs
Carl




From: Ray Hunter [mailto:[e-mail]]
Sent: zaterdag 7 januari 2012 13:44
To: STARK, BARBARA H
Cc: Wuyts Carl; Ole Troan; [e-mail]
Subject: Re: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

Speaking as an end user of the Internet: and in the spirit of your comment on virtual interfaces, why should v6ops make life difficult for itself and get involved at all in corner cases where there is a conflict between what are essentially network operators' deployment decisions, and router vendors' engineering decisions? IMVVVVHO V6ops should not be defining technical workarounds for non-technical problems like the size of the PD assignment.

Various authorities have bent over backwards to ensure that IPv6 addresses are globally plentiful and that they are "very much cheaper" than IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per household seems unnecessarily mean and potentially harmful to transparent end-to-end connectivity on the Internet, possibly forcing end users to deploy complex prefix splitting beyond /64 within their CPE router and thus breaking SLAAC, or perhaps even worse, deploying NAT66.

Perhaps the practical solution for 6204bis would be for v6ops to recommend that network operators delegate "sufficient addresses" to end user sites (as suggested earlier by Ole), and perhaps even going as far as recommending a minimum PD assignment of /60 or /56 for customers using 6204bis compliant equipment. The choice of /60 or /56 being based on the ability to potentially delegate reverse DNS, and to allow end users of the Internet to deploy flexible and reasonable local topologies e.g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 CE router may have one or more network-layer LAN interfaces).

Regards,
RayH

STARK, BARBARA H wrote:

if the network only offers addresses via DHCP, how does the network



trigger the CPE to ask for an IA_NA?



6204 solution is to require the device to always ask.

[Carl]Just configuration, nothing more, nothing less.  If you want

ia_na, ask ia_na, if you don't, don't ask, no need to enforce this.



What if you enforce ia_na and the server doesn't answer anyway ?

Nothing accomplished.  What if you ask ia_na and the server is

configured as such to not hand-out anything if ia_na is requested



(full



match of requested options, if not match fully: nak) Keep it simple,

it's usually the best.  If customer wants ia_na, configure the device

as such, don't expect the CPE to do these things "auto-magically"



this isn't up to the customer. it is a choice by the access network.

and I don't think the "here is a fax from your ISP, just type in these

parameters" scheme is the best we can do. ;-)



[Carl] True, but there will be no "fax" from the ISP to the customer

either to ask to switch something in configuration off either if it

wouldn't work.  Anyway, I'm always flexible, so I say make it a SHOULD

iso MUST, meaning "you should ask it unless you have a good reason not

to do so", no ??





<bhs> The current requirement means that the customer doesn't have to

know anything about the access network (SLAAC or DHCPv6 IA_NA or

unnumbered). When we created 6204, one of the core goals was to identify

requirements that would allow a customer to plug the CE router in and

not have to know what address assignment mechanism the access network

used. Changing WPD-5 from MUST to SHOULD would completely demolish that

goal. If someone doesn't want to design their CE router per 6204, then

there's absolutely nothing that says they have to. It's not a

"standard". But if someone wants to build a router that can come up

without user configuration when connected to an access network that does

either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE

router must do. If someone wants a separate RFC for CE routers intended

for a different environment, then that's fine, too. But 6204 is for the

CE router intended to work in the environment specified in 6204.



As for the virtual interface comment -- my recollection of that was that

CE router designers wanted language that would basically let them put

that "unnumbered model" address wherever made sense for their box: LAN

interface, internal interface, logical interface, whatever. No need to

be specific, and leave it up to them. It just isn't the WAN interface

(because there's an RFC that says that's prohibited). From my

perspective, the CE router is a black box. If the access network

provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to

pick an address from a /64 of the IA_PD and be able to use that address

for sending/receiving traffic to/from the LAN/WAN (while making the

entire rest of that very same /64 available to the LAN for SLAAC). I

think that the new proposals (in the last few emails on this thread) to

split cases around when to put the address on a LAN interface and when

to put it on an internal interface based on =r > /64 in IA_PD go in

exactly the wrong direction. My experience has been that CE router

vendors are perfectly capable of determining the interface that makes

sense for their box. Realistically, the tests run at UNH-IOL wouldn't

check to see what interface the address is on. Because the specific

interface is not externally verifiable. The tests would check for (a) is

the device able to send/receive traffic to/from all ports (assuming LAN

isn't configured for multiple segments) using an address from the IA_PD,

and (b) does it also advertise the rest of that same /64 for use on the

LAN (SLAAC), and (c) do things just work after all this.</bhs>

Barbara