Hi Ole,
Thanks for your comments.
On 10-10-28 05:45 AM, Ole Troan wrote:
Comments/Questions:
1) N:1 deployment model. reference 5517, 3069, 4562 perhaps
OK. Will do.
2) I don't think the deployment model, i.e where you are using a single link
that you are trying to create some level
of 'subscriber isolation on, and require "routing (e.g. on line-ids" in a
middlebox, is restricted to DSL. generalise
the Introduction?
Jari suggested the same. Will do in the next revision.
3) define how the tunneling works, which source / destination addresses are
used. are there other existing signaling mechanisms that be used instead of
'piggybacking' on user traffic to signal to the network.
OK.
4) the proposal is to tunnel ND packets between the AN and the edge router. are
you certain that in this model there aren't other IPv6 protocols that also have
to be tunneled? which would call for a slightly more general approach?
5) does the AN have to do any other action based on the fact that it is
receiving an RS? I'm specifically thinking of state required for SAVI for
example. DHCPv6 is stateful and even though DHCPv6 snooping isn't
architecturally very clean, it is technically a more sound design than trying
to achieve the same with ND. if the answer is no, then please ignore. ;-)
The AN does not need to setup any kind of savi-like state on the receipt
of the RS. The AN does need to setup such state on the receipt of the RA
as is already described in the BBF document WT-177.
6) in section 5.3 you state that the AN MAY retransmit RSs. is how this is done
going to be implementation dependent?
continue forever as in DHCP or timeout after 3 tries as in ND?
My thought was to indefinitely retransmit until an RA is received and
not stop with 3 retries.
if ANCP is available as the section says, is it then specifies how the
signaling would be done? or would that require additional standardisation? I
guess the question is, is this a problem statement, a requirements document or
a solution?
7) why does section 6.2 say that the edge router mustn't decrement the hop
limit of the RA message?
RA messages with hop count <> 255 will be dropped by the receivers as
specified in Section 6.1.2. of RFC4861.
8) in section 6.3. are you stating that you require something like ANCMP to be
able to clean up state at the edge router?
9) section 7. LineIDlen is not in the figure. could you just encode the Remote-ID dhcp option instead? (RFC4649)
<soapbox statement>: I'm biased against this subnet model (N:1)... recreating
PPP functionality over Ethernet, trying to create user isolation on a shared IPv6
link, which after all IPv6 protocols are not designed for.
Fine. I do see why you are objecting to the subnet model. The fact
remains that there are operators using this model and are looking for a
solution to move to IPv6.
what are the options?
- tell BBF not to use DHCPv6?
I think you mean "to use DHCPv6" instead of "not to use DHCPv6"?
- go somewhere else? ANCP? BBF?
There are no other solutions on the table.
- adopt in 6man...
I'm not sure if 6man has the required expertise for this work.
By "this work" Do you mean that 6man
* does not have the expertise for defining a Destination Option
* does not have the expertise for for specifying the process for usage
of the destination option?
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
