RE: CPEs

["Bound, Jim" <Jim.Bound@hp.com>]

Responses in line and I maintained only previous text that had to be kept from me for context in my view.


> The way I see it, we pretty much have all the protocols that we need.
> We probably need one or two additional ones, but at this
> stage, new protocols should be the exception rather than the
> rule. What we're missing is a deployment model, which is
> something close to Alain's social contract. With IPv4, CPE
> vendors have a fairly good handle on what to expect from
> ISPs, and ISPs know what to expect from their customer's
> hosts and CPEs. With IPv6, that's not the case, and the fact
> that we expect more than a single address to be given out to
> a customer and we have several ways to provision these
> addresses defined make this more complicated than with IPv4.
>
> I'm pretty sure the IETF doesn't have all the answers here,
> but I don't see any other organization stepping in, so I
> guess we'll have to come up with something. Obviously that
> must be something that makes sense in the grand scheme of
> IETF/IPv6 things, and it must be something that the vendors
> that come to the IETF support. That's the part we can do in
> v6ops for the most part. But we also need ISPs and probably
> organizations like the DSL Forum to come on board. I'm not
> 100% how we can accomplish that, but I think it will help if
> we can at least agree on a good number of issues here. A wide
> range of viewpoints is represented within the IETF, so rough
> consensus here probably means that we have something fairly solid.

I think the above is a good thing for the IETF to and present an IETF deployment model.  But realize deployment models will be presented and preliminary ones have been by others such as the IPv6 Forum, ATIS, 3GPP, 3GA, WIMAX Forum, etc.  The IETF will a view and an important one but not the only one.

>
> >> Transition
>
> There is a difference between dual stack services and dual
> stack network access. (Hopefully improved) NAT-PT does the
> former but not the latter. I'd say we should probably not
> assume dual stack from the ISP because being able to support
> a single stack model makes the solution stronger.
>
> >> 3. Should a host have the option of signalling to a CPE that it
> >> doesn't require any filtering?
>
> > Absolutely yes or as I state above permit IPsec to pass through.
>
> It seems we have yet to reach consensus, rough or otherwise,
> on this point...

Again there will be other views of deployment for security options in the market and one size does not fit all. IPsec end-to-end where all that is seen is the IP header causes no more attacks than currently but it does put pressure on routers, switches, servers+storage, CPE, and other edge devices to compete with the emerging high-end processor DPI vendors (both hardware and software) which will enable end-to-end IPsec quite well.  What we need to do for a deployment model is speak to it objectively without vendor agendas, market agendas, or other biases.

On DS or DS Services I strongly believe that the Provider edge must support IPv6 services over IPv4 in addition to domiant IPv6 native attached virtual links to support emerging use of IPv6.

>
> >> 4. Is implementing DHCPv6 snooping and option insertion,
> similar to
> >> what currently happens with DHCP for IPv4, a good option
> for vendors
> >> of broadband equipment, or is a provisioning solution where this
> >> isn't necessary preferable?
>
> > I am not parsing entirely why this is a valid question for
> CPE edge,
> > but can see it as server in the home?  But, for the home
> environment I
> > strongly suggest that stateless IPv6 be used so can you
> re-phrase the
> > question at least for me?  Thanks.
>
> With IPv4 broadband aggregation equipment snoops DHCP and
> inserts an option that holds some kind of port identifier.
> Obviously something very similar can be done for DHCPv6, but
> if this is hard to implement, it may be useful to consider
> alternatives.

Seems like a hack to me because IPv4 cannot perform the same form of stateless autoconfiguration that IPv6 does inherently within the architecture and most implementations I am aware of and one of IPv6 significant technical advantages over IPv4 that has not been back ported to IPv4.  So why not use this advantage will be me position once we begin to work on the model if that is our v6ops course.

>
> >> 7. Is the model where there is a CPE with modem
> functionality but not
> >> router functionality a reasonable one?
>
> > I don't think so and this should be transparent to v6ops
> mission for
> > this thread is my input.
>
> Reason for the question: if ISPs insist on CPEs with modem
> and router functionality integrated, we can skip some issues
> (RAs from ISP to
> customer) but that means the ISP - CPE interface becomes more
> important because if it doesn't work right the user is left
> without recourse.

True but I still think that is transparent to the modem and this is really how are RAs/RSs going to work for a home environment.

Important question is this work or model to be only for the home CPE end and not other target markets for IPv6 deployment?

>
> >> 9. If 8, then what is the value of the M and O bits?
>
> > These would only be valid for CPE devices if DHCPv6 prefix
> delegation
> > is used and though I think that will happen we should not
> assume this
> > as the default but cover both.  I won't respond here on the M and O
> > context or indirection as that could be huge rat hole at this point.
>
> If we don't address the M/O issue this means the CPE will
> have to initiate DHCPv6 prefix delegation always.

Agree and the default I would suggest is stateless unless the bits are set.

>
> >> 12. How do we avoid problems caused by customer equipment MAC
> >> addresses clashing with that of other customers?
>
> > I really hope we don't have to work on this in v6ops or in the IETF
> > this is a standard problem regardless of IPv6 or IPv4?  Or am I
> > missing the specific IPv6 issue?  Thanks.
>
> It's not our issue, but it's something that could impact what
> we can and can't do. For instance, "link layer NAT" that was
> mentioned as a solution to this issue requires an ND ALG.

OK but that is truly ugly and I cannot see any reason for a link-layer NAT just implement device drivers to handle decap/encap/translation/exclusive-or-rehash etc. and don't break the IP Layer.  That way v6ops is transparent within a model.

>
> >> 13. How many devices are allowed to connect to a CPE(m)?
>
> > Absolutely none of the IETF's business.  Sorry this is a product
> > feature set for the vendors.
>
> It's more an ISP issue. If ISPs want this to be exactly one,
> vendors can build in logic that avoids problems when a user
> tries to connect multiple devices anyway.

Yep but still not the IETFs business.

>
> >> 14. What kind of addressing is used between the ISP and the first
> >> CPE(r)? Global customer specific, global shared between customers,
> >> link local only?
>
> > Again all will be used we need to define what the technical details
> > are for each case if we want to take on that much work.
>
> I don't think anyone has a pressing need for this to be any
> particular way, they just want things to work. If we can
> recommend an optimal choice, that makes life simpler for everyone.

That is fair to make a recommendation but not standards-track but informational or BCP.

>
> >> 15. How does DAD work on the subnet between an ISP and customers?
> >> Should hosts and CPEs ignore their own DAD packets when they loop
> >> back to them?
>
> > No one ignores DAD that is required to use DAD per the specs.
>
> I think the spec is unclear here. If I send a DAD ND packet out for my
> IPv6 address and I then receive such a packet also for my
> address, but it turns out that this was a copy of my own
> packet that looped back in a way that isn't obvious locally,
> then assuming the address is in use by someone else is not a
> good idea, because that limits layer 2 topologies for no good
> reason. A simple check to see whether the source MAC address
> is the local MAC address can solve this.

OK but that is just doing proper well behaved programming this is possibly good input to the 6MAN WG as a note.
>
> >> DNS
>
> >> 16. How do we expect customer devices to enter into the DNS?
>
> > As they do today.
>
> Today ISPs often just give a name to every address. If you
> get that address, you get the name that goes with it.
> However, in IPv6 you can't populate a /32 with 2^96 DNS names
> so this will have to happen in some other way.

Hmmm can you say more I don't see this limitation in DNS fields defined?  Thanks.

>
> >> 19. How do users authorize third-party devices (ranging from gas
> >> meters to set top boxes) use of their broadband connection?
>
> > Sorry not the IETF's  business.
>
> True. But the answer is important for us: if it's "put them
> in a separate subnet" this means the CPE model must support
> multiple subnets.

Here I must disagree.  There is a difference between IP config for example multiple subnets and then securing devices.  I don't believe many now agree securing devices based on IP subnet is optimal or secure other than using the IP config to locate the devices.  One view against doing this is if the one subnet is compromised then all those 3rd party devices are compromised.  Also this breaks entirely the view of distributed networking across IP subnets for the advantages a subnet provides and that would be unavailable to those devices.

Thanks
/jim