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

[Wuyts Carl <[e-mail]>]

Well, my final comment on this.

First of all, FYI: operators are our customers, not present in retail.  So all my findings are based upon real life scenarios, not invented.  If I say there's no RA on certain deployments, then it means that there is no RA.  Should they have sent one ?  Probably they should, but they didn't.  does it work: Yes it does.  Operational deployement does not necessarily always line up with the theory of an RFC, this is just a fact, nothing new for IPv6.

I'm just trying to feed in some info from another angle.  I see most contributors in this area are not in our position.
I see you state that you can always ask IA_NA, in fact, looking at those bis reqs, you MUST always ask IA_NA (unless you want some mechanism in place to check for "X Y and Z" to start asking something, but this is no realistic scenario in residential CPE devices).  Please note that lots of operators expect a cheap CPE device, to be able to survice in the market, so putting in lots of extra intelligence is possible, but unlikely to happen.
Please note we try, as all CPEs should do imho, to be compliant with most relevant RFCs.  RFC6204bis being one of them from my point-of-view.

Regs
Carl



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

By actively engaging in the creation of RFC 6204 and 6204bis, the operator community engaged in this effort has effectively said that:
1. Operators who expect 6204(bis)-compliant CE routers to work with their IPv6 access networks won't do things in their IPv6 access networks that will cause these CE routers not to work. Operators who do not expect these CE routers to work in their access networks may well do things that cause these CE routers not to work in their access networks. It is absolutely true that a 6204(bis)-compliant CE router cannot be expected to work in an environment where it is not expected to work.
2. Operators who expect 6204(bis)-compliant CE routers to establish a native IPv6 connection with their access networks will send RA. That RA may or may not have a SLAAC ("A") prefix. This includes operators who do PPP. See BBF TR-187 http://www.broadband-forum.org/technical/download/TR-187.pdf. [Things may change in the future, but that change will have to be coordinated.]
3. Operators who expect 6204(bis)-compliant CE routers to establish a native IPv6 connection with their IPv6 access networks will have a DHCPv6 server that provides IA_PD and DNS. It may or may not supply IA_NA or other config info.

The above operator expectations are implicit in RFC 6204(bis).

The requirements tell the CE router that
a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you aren't expected to be able to establish an IPv6 connection with this access network.
b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A" prefix, that's ok. Clearly, the access network doesn't expect you to do SLAAC if it doesn't send an "A" prefix. If it does send an "A" prefix, then it does expect you to do SLAAC.
c) It's OK to always ask for IA_NA. But if M=1, then you MUST ask for IA_NA. If you get an IA_NA offer, take it. If you don't get one, that's ok. If the access network doesn't offer an IA_NA after you've asked for one (or if M=0), then clearly it doesn't intend for you to have one.
d) Always ask for IA_PD. If you don't get IA_PD, then you aren't expected to be able to establish IPv6 connectivity for your LAN. This access network has no intention of supplying your LAN with IPv6 connectivity.
e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then take a single address from a /64, and associate it with an interface (not the WAN interface) where you can use the address for sending/receiving traffic to/from the LAN/WAN. IMO, the entire rest of the /64 should always be available for use in the LAN. The "unnumbered" model should never lock up an entire prefix. But we don't say that anywhere. So I guess operators can't expect this to be the case. I wouldn't be opposed to either stating that the unnumbered model might lock up a /64 prefix, or requiring that it not lock up a /64 prefix. But how to not lock up a prefix (if that's required) should be up to the CE router vendor to implement.

It's important to understand that if an operator wants these CE routers to work with their access network, then the operator won't do things that will cause the device not to work. If an operator doesn't want the CE router to work with their access network, then you shouldn't expect to be able to create requirements that will allow the device to work. Operators should expect CE routers to request IA_NA, independent of what the operator puts in the RA (M bits, "A" flags). I agree that it's not a good idea for the operator to support both SLAAC and IA_NA. And operators know this. Contrary to popular belief, we aren't clueless. While these requirements do not preclude stupidity in access network design, operators are working hard (and together) to avoid stupid access network design. And we're working with the CE community to try to make sure that we express (reasonable) expectations for devices to work with the access networks we design. Again, you're absolutely correct that the expectations we've expressed are not intended to ensure that the devices work on access networks of operators that have not been engaged in creation of 6204(bis). But I can only assume that such operators have no interest in such interoperability. Otherwise, they would be here.
Barbara


From: Wuyts Carl [mailto:[e-mail]]
Sent: Monday, January 09, 2012 2:16 AM
To: Ray Hunter; STARK, BARBARA H
Cc: Ole Troan; [e-mail]<mailto:[e-mail]>
Subject: RE: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

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]<mailto:[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