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

["Tony Hain" <alh-ietf@tndh.net>]

Margaret Wasserman wrote:
> Hi Tony,
> 
> ...
> 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.

That is easy to fix, though there is no requirement for complex large scale
deployment as rfc2453 (ripv2) would do the job and be easy enough to
self-administer/auto-conf in a dentist office scenario. 

> ...
> > 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?

Split-DNS would make the non-local case more efficient, but it is not a hard
requirement like it is with IPv4/nat. Given that enterprises have nodes that
they don't want the world to know about they are likely to be running some
form of split-DNS anyway, so I don't see this as a big deal either way.

> 
> ...
> 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, 

There is nothing magic about the topology masking router and forwarding
solicited-node multicast is not required. ND runs between the
topology-hidden node and the router it really attaches to. For traffic from
other nodes that might be actually attached to the logical subnet, the state
of the on-link flag would indicate that those nodes should forward the real
traffic via the router if their ND fails. Any other node (in that subnet or
not) would forward via their local router and the routing system would
deliver the traffic to the real attachment point because that is what the
IGP says to do.

> 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.

Subnet local multicast to a collection of nodes that are scattered makes no
technical sense, but you are correct there is nothing in the document that
talks about the issue. If someone could suggest text I would appreciate it,
but I will see what I can do to identify the point. 

> 
> > ...
> > One needs to pay attention to the distinction between 'link' and
> > 'subnet'.
> > ...
>
> 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?

Registration with the topology masking router is only a property of the
MIPv6 approach. The IGP route injection approach effectively registers with
the first hop router. Either way the configuration does not need to be
manual, though that would clearly work. I don't know all the mechanisms that
hosts might use to configure a home-address/home-agent, but a similar
approach would work for the route injection technique specifying the
logical-address/IGP-type. In either case when the received RA does not match
the home/logical address prefix then the logical prefix would be considered
off-link. One could either manually mark it up front or discover the fact
due to the mismatch between the topology hidden prefix and the locally
attached one.

> 
> >>> (5) Would autoconfiguration be used on the logical subnet, or would
> ...
> 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?

I wouldn't bother with a specific option since that can be derived from the
difference between the home/logical-address and the currently attached
prefix. It is also not clear configuration needs to be manual. Since there
is no hard and fast requirement here is seems like this discussion is
outside the scope of describing that techniques exist to eliminate the
perceived need for nat.

> 
> > ... 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.

To be complete, you are talking about the specific topology hidden subnet
being virtually connected to the topology hiding router using an L2 VLAN
approach. There may be other subnets in the network that share the same L2
hardware as different VLANs, but those are interconnected to the topology
hidden subnet via the L3 topology hiding router. If you were really talking
about a single flat L2, then there is no L3 topology to hide.

> 
> >>> 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.

While I agree, that distinction does differentiate our process expectations
and the depth of detail is necessary. If you believe strongly that a BCP is
required, please write one to follow this. Right now we need a document that
dispels the myth that a nat is required to accomplish these tasks. 

> (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?

There is nothing really magic about a topology hiding router. In the MIPv6
case it is a standard HA and does what HA's do to support remote nodes that
are not doing route optimization. In the IGP case it doesn't really have to
do anything (and may not even have a real interface for the virtual subnet)
because the IGP delivers the bits to the actual attachment point no matter
where they come from. 

You say later that this should not be a tutorial though here you are arguing
that it should be. Host routing is not rocket science, and the only cases it
becomes a scaling problem are those where the network manager should have
enough expertise to recognize what they are getting into. MIPv6 is a new
enough technology that it might not be well understood, but tunneling is
well understood and widely deployed. All we are talking about here is
leveraging the automatic tunneling feature of MIPv6 to avoid the need for
manually configuring tunnels. In the -03 version added a fair amount of text
to describe the MIPv6 approach in more detail, and will add more if it is
really unclear. 

> 
> ...
> 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.

There is nothing to describe. If you think there is something special here
please send text to describe the magic for assigning hosts from a specific
/64 where there is no physical interface on any router with that prefix.
Since in one case the hosts are injecting their address set directly into
the IGP, they effectively become the router for each of those /128's. In the
MIPv6 case the standard HA would need to tunnel forward, but there is no
need for the topology hidden subnet to really exist on a physical interface.
The function is to virtualize the appearance of that subnet at/near the edge
of the network just as those nodes would appear from the outside of a nat.

> 
> 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.

I expanded the trade-off discussion in -03 which should cover point 2, even
for the L2 VLAN approach. We don't require point 1 even for standards track
documents (see shim6), and for point 3 the reason for listing alternatives
is that the qualitative judgment really depends on the specific use case. In
any case this is a market call not an I* pronouncement. 

Tony