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

Re: Review of draft-ietf-v6ops-nap-02.txt


Hi Tony,

On Jul 12, 2006, at 10:29 AM, Tony Hain wrote:
Clearly if the network has 50,000 devices it is no longer 'simple'. The mechanism works for the simple router case when the number of devices aligns 
with the context of a 'simple' network.
There still seem to be some conflicting statements in the draft about the applicability of the route injection topology hiding mechanism. Presumably, we are talking about an enterprise-level deployment, because it depends on the use of an IGP, but the diagram says "simple gateway or home gateway". I would rather it said "topology masking router", as you have described it later. 



(3) How will local nodes know to use topology-specific ULA
addresses for
local communication?
RFC 3484 policy table entry biasing FC00::/7 as preferred over 2000::/3
This response does not answer my question. I understand how this will work iff internal nodes are given a ULA as a possible destination address for local nodes, but I don't understand how the local nodes will be given the ULAs. Do you anticipate the use of split-DNS in this scenario, so that ULAs are supplied internally and not externally?
One of the problems with NAT, at least from my perspective, is that they require a split-DNS employment to get local name resolution. Are we expecting that NAP will have that same property? 


(4) How does this interact with multicast traffic and ND.
ND for the topology hidden unicast & general multicast traffic would route 
via the topology masking router.
It is clear from this and earlier responses that a "topology masking router" is a special beast with some different properties than a regular router, such as logic to forward solicited node multicast packets to the set of potentially matching nodes, the ability to forward subnet-local multicast to all of the nodes on the logical subnet, etc. I think that you should describe these properties when asserting that IGP route injection can be used for topology hiding. 


Can anode on the
"logical subnet" send a link-local multicast packet on the logical
subnet
and safely assume that it will reach all of the nodes on that
subnet and no
one else?  If not, how does this interact with ND?
One needs to pay attention to the distinction between 'link' and 'subnet'. If a node is part of a logical subnet and knows it is not directly connected 
to the link attached to the hosting router (because the flag is set to
not-on-link for that prefix), then it should not assume anything about LL reachability of any other member of the subnet. ND will work as defined, so the topology hidden node will use its LL to talk to whatever router is on 
the link, then use routing to get to anything else.
This is quite a complicated topic that has been discussed in various places, and I don't think that either of us wants to re-hash all of those discussions here or in this document... It isn't clear to me that this works as cleanly as you seem to think, but that is almost certainly outside the scope of this document.
Since you later seem to indicate that these nodes won't receive RA's, though, I'm not sure where we would clear the on-link flag. Maybe via manual configuration when we set-up the addresses and identify the router with which these nodes should register? 


(5) Would autoconfiguration be used on the logical subnet, or would
hosts be
expected to get those addresses through other means?
They would have to use other means because they need to also inform that node that it is supposed to use that address rather than whatever might be 
offered for where it attaches.
Perhaps you could make it clear that this mechanism relies on manual configuration of IP addresses, the (local topology) address of the router with which to register, and the on-link flag on each of the topology-hidden hosts? Should we be considering a DHCPv6 option to provide a topology hiding prefix? 


(6) What advantages (if any) does this approach have over using a
single
subnet internally and using L2 switches and VLANs to handle
internal packet
delivery?  What disadvantages does it have when compared to that
approach?
That works. We specifically took it out of the initial draft because it was not an IP level mechanism. I put it back after hearing you were concerned about it. The primary disadvantage is that all traffic has to route via the topology hiding router, and the L2 has to have the means to create the vlan.
I will have to look at what you've added again, because I think we are having a misunderstanding. I am merely saying that you would use a bridged network (no L3 topology). Your local physical topology would be handled at L2, with the appearance of a completely flat network at L3. 


If we decide that we actually want to make this recommendation,


It is not a BCP, it is simply information.


Two comments on this:
(1) I don't think that readers make a big distinction between BCP and Info. (2) Even in an informational document, I don't think it is reasonable to refer to a solution as though it is a well-understood solution when it is not. If we want to discuss this solution, I think we need to say enough for readers to understand how the solution actually works. It isn't sufficient for users to just insert host routes in current routing equipment if that equipment does not include other features to be a "topology hiding router", right? 


I'd prefer
that we remove it from this document and make this recommendation in a 
separate document that covers the scalability issues, the answers my
questions above, and any other factors that may affect the
applicability of
this solution.
A BCP should be a separate document. The full -03 round of edits covers the scale issue. It is not clear to me that it needs to be a primer on IPv6 to 
discuss the distinction between link and subnet and how ND works.
I don't think we need a primer on IPv6, but I do think we need some description of the topology hiding router and its properties.
We also need to decide if we have consensus that such a solution is a good idea, because regardless of the document classification, this document is stating how IPv6 can provide the benefits of IPv6 NAT, and I don't think we should state that IPv6 can be used in a certain way to provide certain benefits unless we think: (1) it will work, (2) any downsides of the approach are mentioned, and (3) the downsides are not worse than the benefits. 

Margaret