[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 broadband provisioning

On 31 dec 2007, at 8:22, Mohacsi Janos wrote:
In my opinion if the ISP router send out RAs is easier to control - except no ipv6 transparency possible 

What does "no IPv6 transparency possible" mean?
These models are already described in the RFC 4779. What is the goal of this discussion? It is clear that, The address alignments has to be defined. What else?
The point is to show that it's doable to have stateless autoconfiguration for subscriber hosts connected to a bridged CPE. 

On 30 dec 2007, at 11:33, Mark Smith wrote:


The issue that I see is that of duplicate MAC addresses. I don't see
an easy way to protect against that. How does this work today in a N:1 
model?



The DSLAMs we use perform MAC address - wait for it - NAT, into
algorithmically calculated MAC addresses, in part based on line card
and node IDs.
Which of course creates all the usual problems that NAT always creates: what about protocols that embed the translated addresses? In this case, that would be neighbor discovery. 


It's ugly thinking about all the FCSes that are being
recalculated all the time


That happens in the ethernet hardware, not an issue.

On 30 dec 2007, at 1:21, David Miles wrote:


The core questions that need discussion are:
- How likely bridged CPE is for IPv6 broadband deployments? (Where there is no IPv6 router between subscriber node and the ISP network)
Hard to say, but unless you want to buy a somewhat expensive Cisco CPE that runs IOS (I gather that the "easy" configuration works much better these days but I wouldn't count on it too hard) a bridging CPE is the only way to easily provide native IPv6 connectivity today.
- Whether stateful DHCPv6 or stateless autoconfig is supported for nodes behind the bridged CPE
Maybe at some point in the future all IPv6 hosts will support DHCPv6 address configuration, but there is no way that's going to happen any time soon. I believe people from Apple have said that they're not interested in supporting DHCPv6.
- If we have agreed that DHCPv6 PD is the way to go for routed CPE, don't we still need to address the issue of identifying the CPE (hence the L2 DHCPv6 relay agent in the access node)
See my earlier message, if the DHCPv6 client uses a global address learned from subscriber-specific RAs then there is no need to mess with DHCPv6 in layer 2 devices. 


- DAD has issues in the N:1 VLAN approach


I think that can be solved unilaterally by the ISP infrastructure.


what is the advantage of bridging?


Switches are cheap and simple.


There is no stateless autoconfiguration for link locals.
[DM] Are we talking semantics here? On an Ethernet link, EUI-64 is appended (as interface ID) to fe80::/64, and DAD is performed on that address. RFC 2462 says "the autoconfiguration process includes creating a link-local address".
Stateless address autoconfiguration = creating addresses based on router advertisements. That doesn't apply to link locals.
then move to DHCPv6 for prefix delegation (ie, M-bit=0, O-bit=1 in the RA). 


Hm, is that the appropriate combination for DHCPv6 PD?
[DM] If I'm interpreting RFC 2462 correctly and do not want the interface address to be assigned by DHCPv6, then there is no need to set M=1. RFC 3633 does seem to separate address assignment from prefix delegation (section 7). Perhaps worth clarifying whether M- bit must be set for PD?
With M=0 O=1 I'd think a client would initiate the stateless variation of DHCPv6. For prefix delegation you'd need the stateful version...
That's not necessary in my model, the aggregation switch only needs to be able to send RAs that are always the same except for a few bits in the prefix option. (Probably in reply to router solicitations.) There is no need for a full or even a partial IPv6 implementation or much in the way of parsing incoming messages.
[DM] Appreciate that today the DSLAM insert an opaque value into the DHCP Option-82 field. If we start modifying the PIO in the RA with per-subscriber info then the DSLAM/access switch will need to have information about IPv6 prefixes? Ie, does this customer get a ::/56, or a ::/64, etc? 

Stateless autoconfig only works with /64...


The problem I see with stateless autoconfig is that:
- It requires every RA to be unique to each subscriber
- In an N:1 network, only the access node/DSLAM can create per- subscriber unique RA - RA are sent regularly (at least ever 30 min, default 10 min) as a MC, so the access node must intercept, and create several hundred "modified" RA - Instead of the line-Id being an opaque value that a DHCP(v6) server uses to determine appropriate prefix, the line-id now forms a fundamental part of the IPv6 address prefix.
I don't see these as particularly problematic. It would of course be nice if the aggregation switches wouldn't have to do anything, but guess what, if you want to have per-subscriber settings you really need to do per-subscriber work SOMEWHERE.
I would like to explore this part with others as part of discussions within the DHC WG on this issue.
I don't think that makes sense, none of this requires changes to DHCPv6.
[DM] Sorry, I wasn't being very clear, I was referring to L2 DHCPv6 Relay Agent.
Like I said, I'm pretty sure we can avoid doing stuff like that. (Also DHCP relaying is a layer 3 function, not a layer 2 function, inserting option 82 or some such is not relaying proper.)
Not sure what the issue is with neighbor discovery. As for DAD, for global unicast that's not an issue because different subscribers use different prefixes. So that leaves link locals. This can be solved by having the ISP router do proxy ND for this specific purpose to address the corner case where the link local address isn't MAC-derived. (The MAC address was unique, right...?)
[DM] Proxy ND was really made for relaying ND between different links. In this case we have two nodes on the same "link". Again, definition of link is the problem, from the ISP router, there is one link with many subs. From the subs perspective there is a point-to- point link (of sorts) between them and the router.
Does that matter? The point is that the ISP router sends out a packet to make DAD fail if a host tries to configure an address that's already in use. Not sure though what the host holding that address previously will think about seeing that proxy ND packet...
It's unclear what happens in the case where the original DAD message loops back to the sending host. Hopefully hosts are smart enough to detect and ignore this condition.
This is the problem I'm trying to describe - hosts are not smart enough to "detect" this condition because there is no way they can determine whether the Neighbour Solicitation was from them or from someone else. Checking link-layer isn't really valid (per Appendix A discussion) unless you are sure two devices with duplicate MACs cannot exist on the same segment
With duplicate MAC addresses you're screwed anyway so trying to address that situation doesn't help. So I think it would very appropriate for hosts to check for their own link address in incoming ND packets when doing DAD.
But this isn't relevant to our discussion, because if there are two hosts with the same address on that N:1 network they won't know because they can't send packets to each other directly