Subject: Fwd: Review of draft-ietf-v6ops-nap-02.txt

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Jul 2006 09:43:02 -0400

FYI --

Here is the message I mentioned in today's meeting.  My questions are  
near the end.

Margaret

---

Begin forwarded message:

> From: "Margaret Wasserman" <[email-masked]>
> Date: June 28, 2006 5:17:16 PM EDT
> To: <[email-masked]>
> Cc: "'Tony Hain'" <[email-masked]>, "'Tim Chown'"  
> <[email-masked]>, "'Radia Perlman'" <[email-masked]>,  
> "'Alex Zinin'" <[email-masked]>, "'Erik Nordmark'"  
> <[email-masked]>, <[email-masked]>, "'Dave  
> Oran'" <[email-masked]>, "'Bill Fenner'" <[email-masked]>,  
> "'Jari Arkko'" <[email-masked]>, <[email-masked]>
> Subject: RE: Review of draft-ietf-v6ops-nap-02.txt
>
>
> Hi All,
>
> As I understand it, there is a current proposal in the v6ops WG (in
> draft-ietf-v6ops-nap-03-draft0.txt) to publish the following  
> recommendation:
>
>    There are other possible scenarios for the extreme situation when a
>    network manager also wishes to fully conceal the internal IPv6
>    topology.  In these cases the goal in replacing the IPv4 NAT  
> approach
>    is to make all of the topology hidden nodes appear from the outside
>    to exist at the edge of the network, just as they would when  
> behind a
>    NAT.
>
>    o  One could use explicit host routes and remove the correlation
>       between location and IPv6 address.  In the figure below the  
> hosts
>       would be allocated prefixes from one or more logical subnets,  
> and
>       would inject host routes to internally identify their real
>       attachment point.  This solution does however show severe
>       scalability issues and should be limited to uses with
>       substantially fewer than the maximum number of routes that  
> the IGP
>       can support (generally about 50,000).
>
> [...snip...]
>
>                              Internet
>                                  |
>                                  \
>                                  |
>                        +------------------+
>                        | Simple Gateway   |  Logical subnet
>                        | or Home Agent    |-+-+-+-+-+-+-+-+--
>                        +------------------+  for topology
>                                  |           hidden nodes
>                                  |
>                Real internal  -------------+-
>                topology       |            |
>                               |           -+----------
>                    -----------+--------+
>                                        |
>
>
>
> The more I think about this proposal, the more questions arise,  
> such as:
>
> (1) Do we really mean that the router in this picture would be a  
> "simple
> gateway or home agent"?  I don't think that is consistent with the  
> idea that
> it could handle 50,000 routes.  Or that it would run an IGP, for that
> matter.
>
> (2) What mechanism would hosts use to inject host routes into the  
> IGP?  How
> is that secured?
>
> (3) How will local nodes know to use topology-specific ULA  
> addresses for
> local communication?  What happens if they don't?  Could this  
> result in a
> large amount of internal traffic bouncing off of the "simple  
> gateway or home
> agent"?
>
> (4) How does this interact with multicast traffic and ND.  Can a  
> node 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?
>
> (5) Would autoconfiguration be used on the logical subnet, or would  
> hosts be
> expected to get those addresses through other means?
>
> (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?
>
> (7) How does this proposal relate to the work currently underway in  
> the
> TRILL WG?
>
> If we decide that we actually want to make this recommendation, 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.
>
> Margaret
>
>
>> -----Original Message-----
>> From: Fred Baker [mailto:[email-masked]]
>> Sent: Wednesday, June 28, 2006 4:00 PM
>> To: Margaret Wasserman; Dave Oran; [email-masked]
>> Cc: 'Tony Hain'; 'Tim Chown'; [email-masked]
>> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt
>>
>> Radia and Dave:
>>
>> There is a dispute going on regarding the scalability of
>> topology hiding by what amounts to IS-IS level 1 routing
>> (identifying hosts in a multi-LAN network by their host
>> identifier and using a common subnet ID for the domain). Do
>> you know of available documentation of IS-IS level 1 routing
>> and its tested scalability?
>>
>> As Radia knows, this question is also being looked at in IEEE
>> 802.1, which presumes that there is only a single
>> multi-LAN-LAN, and that MAC addresses are used to route within it.
>>
>> Fred
>>
>> On Jun 28, 2006, at 12:40 PM, Margaret Wasserman wrote:
>>
>>> 50K is an order of magnitude higher than the analysis in
>> Alex Zinin's
>>> presentation would seem to indicate.  His presentation
>> indicates that
>>> flat
>>> routing will only scale to something on the order of 1K nodes.
>>> Please feel
>>> free to check with Alex, though, as he certainly has more
>>> understanding of IGP scaling than I do.
>>> [snip]
>>> If this document is going to recommend doing flat routing
>> for topology
>>> hiding, I think that the WG needs to do the analysis to
>> determine that
>>> this is a valid and scalable technique.
>>
>
>

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 12 Jul 2006 07:29:51 -0700

> >       can support (generally about 50,000).

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. 

> > IGP? 

They participate in the IGP as 'routers' for the set of addresses the host
might be using.

> > How is that secured?

In what ever mechanism the network uses for securing its IGP. If your real
question is about 'trust of hosts' vs. routers, the point that needs to be
kept in mind here is that in simple networks the policy manager is the same
between the hosts and routers. 

> > local communication?  

RFC 3484 policy table entry biasing FC00::/7 as preferred over 2000::/3

> > What happens if they don't?  Could this
> > result in a

Yes, if a node doesn't prefer the addressing that will result in the
shortest path, then the traffic will bounce via the topology masking router.

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

> > Can anode on the

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. 

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

> > delivery?  What disadvantages does it have when compared to that

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.

> > (7) How does this proposal relate to the work currently underway in

It doesn't. TRILL is trying to logically concatenate links. This mechanism
is simply using MIPv6 or Host routes to make the host appear at the edge of
the network like it would in an IPv4/nat case.

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

It is not a BCP, it is simply information. 

> > I'd prefer

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. 

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Jul 2006 13:49:35 -0400

Hi Tony,

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

> RFC 3484 policy table entry biasing FC00::/7 as preferred over  

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?

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

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

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

> topology hiding router, and the L2 has to have the means to create  

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.

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

> 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

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 13 Jul 2006 12:07:39 -0700

Margaret Wasserman wrote:
> ...

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. 

> ...

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.

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

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. 

> > ...
> > ...

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.

> ...

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

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.

> (1) I don't think that readers make a big distinction between BCP and

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. 

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

> ...

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.

> 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

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Jul 2006 20:29:29 +0100

> but I will see what I can do to identify the point. 

I think this is a very good point.  Clarification of use of multicast 
would be appreciated.

Tim

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 16 Jul 2006 09:05:12 -0400

You might also want to note that Duplicate Address Detection (DAD)  
will not work on the logical subnet(s).  I realize that DAD doesn't  
find collisions very frequently in the case of auto-generated  
addresses, but the logical addresses will not be autoconfigured from  
RAs.  If they are manually configured, extra care needs to be taken  
because of the lack of DAD.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 16 Jul 2006 07:26:11 -0700

> because of the lack of DAD.

The device would run DAD on the link it is attached to, but you are correct
that is not going to cover the logical subnet. If it seems necessary and
within scope I could put in a comment about listening to the IGP before
announcing to see if the address already exists for that case, then for the
MIPv6 case the HA already detects duplicates and denies the binding. 

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Jul 2006 23:29:32 +0200

...
> form of split-DNS anyway, so I don't see this as a big deal either way.

Personal opinion: in enterprise network deployments, split DNS is as
likely to go away as firewalls. If an enterprise has internal servers
that it wishes to hide from the outside world, split DNS is inevitable.
As Tony says, NAP will work without it (i.e. if a ULA appears in global
DNS, it will be unrouteable) but I bet it will be as widespread in IPv6
as it is for IPv4.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Jul 2006 08:53:31 -0700

On split-DNS, I have been studying address configuration in
a different context lately (NETLMM wg) and am leaning toward
a model in which nodes within an enterprise would use global
addresses only for communications with nodes in other
enterprises and would use ULAs for communications with nodes
in the same enterprise. So, that would automatically imply
split-DNS. Would that be a problem?

Fred
[email-masked]  

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Saturday, July 15, 2006 2:30 PM
To: Tony Hain
Cc: 'Margaret Wasserman'; [email-masked]
Subject: Re: Review of draft-ietf-v6ops-nap-02.txt

...

    Brian