Subject: Re: [DNA] DNAv6 Review from Mobopts

From: JinHyeock Choi <[email-masked]>
Date: Tue, 08 Jan 2008 04:45:52 +0430

Dear Wes

Thanks for your kind and prompt reply. Kindly see my in-line comments.

> > Our basic assumption was that a prefix can't be assigned to more than
> > one link at the same time. The > above example constitutes 'multi-link
> > subnet'. Is such a configuration legitimate in current standard?
>
> Not only is it completely legitimate to use "multi-link subnet", it's
> actually the common case.

In Sec 2.1 of RFC 3513, it's written that

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

from which, we assumed that 'multi-link subnet' is not legitimate,
while unfortunately it may be the case in some circumstances.

> Cable MSO's are planning on deploying 10
> million+ subscribers on a "multi-link subnet" for IPv6.  This means that
> entire neighborhoods of homes will be on the same "multi-link subnet".
> I presume that you want to target DNA for wireless access points for
> home routers.  Unfortunately, the majority of homes will eventually be
> on "multi-link subnets" which are geographically co-located.  Therefore,
> DNAv6 in its current form will likely malfunction even for the wireless
> access points that you are targeting.

I can't understand why Cable MSO wants to share IPv6 prefixes among
different links. Such a deployment may make sense in limited IPv4
address space but, IMO, not in IPv6 case. For example, in 3GPP and
WiMAX, it's even recommended that one prefix is assigned for one
mobile node. Unless Cable MSO already burnt a bridge and are totally
committed to multi-link subnet, we'd better recommend "DON'T".

Moreover, I don't see much need for DNA when a mobile node moves
between different homes. DNA is to reduce movement detection time to
achiever seamless handoff but, when you visit a house, at least you
should ring a bell and wait for a reply. :-)

> > Moreover, in such a case, I don't know why a common prefix is
> > advertised at all. The prefix can't be > used for SLAAC or on-link
> > determination. Neither A bit nor L bit can be configured for the prefix.
> > So what's the use of advertising the prefix?
>
> On-link determination and SLAAC in "multi-link subnet"'s is a very
> complicated subject.  We've written some Internet drafts to address the
> problem - but the short answer is that it can be done within the
> confines of the existing specifications, but it is rather tricky.

Maybe it can be done but I still don't understand 'why it needs to be
done at all'. My point is that, in a scenario you described above,
there is no need to advertise a common prefix (and confuse DNA
operation) in the first place. You want a mobile node to send all
traffic to its default router, so L-bit is unnecessary. And I assume a
mobile node is supposed to use DHCP, so A-bit is also unnecessary. It
won't serve any purpose to advertise a prefix with neither L-bit nor
A-bit.

> In short, I suggest that the next version of the DNAv6 (if there is one)
> seriously consider "multi-link subnet"s as a possible deployment
> scenario, and that it be specifically designed to work in that case.
> The other option is to have the option to turn off DNAv6 in homes which
> are part of a "multi-link subnet" - but that would limit the usefulness
> of DNAv6.

If multi-link subnet can't be avoided and will be widely used, we
should incorporate the case. But the simplest and cleanest solution
would be to avoid it. I assume the main purpose of multi-link subnet
is to save address space. Taking IPv6 address space size in to
consideration, I wonder whether such a saving is worth introducing
more complexity. In case there is another benefits from multi-link
subnet, kindly let me know.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 10 Jan 2008 04:35:29 +0430

Dear Wes

> The reason cable MSO's use multi-link subnets is that there is no
> connectivity between homes (for security and bandwidth purposes), so the
> alternative is that every home gets its own prefix.  Cable MSO's have
> chosen instead to share one prefix for every 100,000 homes.  This is to
> conserve IPv6 address space, which may actually be more limited than you
> might think. (Try requesting some someday! I had a lot of difficulty
> getting a /55 when I needed one!)  The powers that be wisely want to
> control the IPv6 address situation so that we don't end up in the same
> mess as we have for IPv4.  Given the perceived shortage of IPv6
> addresses, DHCPv6 PD service for 100 million homes may be harder to
> obtain than you might think.

hmmm. From 3GPP and WiMAX examples, i.e. generously allocating a
prefix per a mobile node, I assumed that it won't be necessary to
share a prefix among homes. Let's see.

> Good point!  Which means it may be perfectly acceptable to say "the
> transition will not be seamless when you move between houses" or "you
> may have to reset your network card when you move between houses" - but
> that means that the failure mode should be that you get no connectivity
> and it requires manual intervention rather than it "seamlessly thinks it
> works but actually creates mysterious, hard to understand behavior"
> which I think is what the current spec does.  That's why I say that one
> perfectly acceptable behavior is just to revert to regular ND (or have
> the option of regular ND) and require manual intervention in case of
> these types of network changes.

The problem is that regular ND doesn't talk much about how to
determine if a host's existing address is still valid. As of my
knowledge, there are two ways in ND,
1) check whether the prefix of the address is advertised in the
currently attached link.
2) check whether an existing default router is still reachable.

1) gives a problem in multi-link subnets as you pointed out.
2) gives a problem because of link-local scope of router address.

thanks for your sharing ideas with us. I wish you would also comment
on the existing simple DNA solution to facilitate its advancement.

Best Regards

JinHyeock

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 09 Jan 2008 22:15:22 -0800

> 2) gives a problem because of link-local scope of router address.

For ND detection, you need to check the MAC address as well.  That way
the existence of the same link-scope address on multiple links is not
an issue. 
 
> on the existing simple DNA solution to facilitate its advancement.

At first look, Simple DNA does not seem to have these issues because
it can support fast reuse of DHCPv6-assigned addresses, and also because
it can function even when no prefix is advertised in the RA.

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 10 Jan 2008 12:51:28 +0430

Dear Bernard

thanks for your comments. glad to hear from you again.

> the existence of the same link-scope address on multiple links is not

It may cause some problem for DNA scheme to rely on MAC address as below.

First, in certain technology such as 802.16, MAC address is not used
for data transfer. In some implementation, when a host performs
address resolution to find the router's MAC address, its device driver
intercepts the message and provides a bogus MAC address.

Moreover, when a host moves to another subnet/ link, it won't speed up
DNA procedure to check whether its existing default router is still
reachable. So the scheme will give little help when, IMO, fast DNA is
needed the most, i.e. when a host doesn't have a valid address, so
should get a new one ASAP.

> it can function even when no prefix is advertised in the RA.

I'll be happy that Simple DNA would do the job. I'll go over the draft
and comments on ML.

Best Regards

JinHyeock

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Jan 2008 11:05:11 -0800

> It may cause some problem for DNA scheme to rely on MAC address as below.> > First, in certain technology such as 802.16, MAC address is not used> for data transfer. In some implementation, when a host performs> address resolution to find the router's MAC address, its device driver> intercepts the message and provides a bogus MAC address.
 
So the device driver is spoofing a response to the Neighbor Solicitation? 
Won't this cause problems if and when SEND is implemented? 
> Moreover, when a host moves to another subnet/ link, it won't speed up> DNA procedure to check whether its existing default router is still> reachable. So the scheme will give little help when, IMO, fast DNA is> needed the most, i.e. when a host doesn't have a valid address, so> should get a new one ASAP.
 
Since ND and RS/RA are done simultaneously in simple DNAv6, the completion
time is determined by the faster of the two exchanges.  In the case where the
host doesn't have a valid address, the ND exchanges will fail (no response),
and the host will obtain an address via the normal RS/RA procedure.

---

From: "Johnston, DJ" <[email-masked]>
Date: Thu, 10 Jan 2008 12:30:46 -0800

In 802.16, the MAC address is not used for data transfer in only the
IP-CS mode, which is not strictly an 802 thing. In the Ethernet
emulation modes, it certainly is. Also in the IP-CS modes, the MAC
addresses are known at both ends of the connection.

An IP-CS connection is more akin to a point to point IP link than an
Ethernet. The decision to send a packet down the connection is a L3 one.
L2 has only one connection to send it down, address resolution is moot.
Such spoofing sounds like a hack to satisfy an address resolution
attempt that shouldn't be happening because the interface doesn't
warrant it.

DJ

----

David Johnston. [email-masked] Cell: 503 380 5578, Desk: 503 712
4457

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Aboba
Sent: Thursday, January 10, 2008 11:05 AM
To: JinHyeock Choi
Cc: Wes Beebee (wbeebee); [email-masked]; Hemant Singh (shemant);
[email-masked]
Subject: RE: [DNA] DNAv6 Review from Mobopts

> intercepts the message and provides a bogus MAC address.
 
So the device driver is spoofing a response to the Neighbor
Solicitation? 
Won't this cause problems if and when SEND is implemented? 

> should get a new one ASAP.
 
Since ND and RS/RA are done simultaneously in simple DNAv6, the
completion
time is determined by the faster of the two exchanges.  In the case
where the
host doesn't have a valid address, the ND exchanges will fail (no
response),
and the host will obtain an address via the normal RS/RA procedure.

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 11 Jan 2008 04:23:45 +0430

> Sure thing.  Please send me a copy of the current drafts/point me to
> their location and I will look at it when I have the time.

http://www.ietf.org/internet-drafts/draft-krishnan-dna-simple-01.txt

best regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 11 Jan 2008 04:24:47 +0430

>  Won't this cause problems if and when SEND is implemented?

It spoofs a solicitation and just replies the message for itself. NS
message won't go out of a host. It may cause a problem for SEND and
some other cases.

>  and the host will obtain an address via the normal RS/RA procedure.

So for handoff cases, DNA performs no better than existing ND. In
other words, DNA contributes little for seamless handoff. I wonder
whether it's an enough improvement.

best regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 14 Jan 2008 06:27:52 +0430

Dear Hemant

Thanks for your kind elaboration, which made me understand the cable
case the better, I hope. :-) I assume that, in CMTS, 'bundle of L2
links' form a kind of single (virtual) L3 link. While working on DNA,
I found out that the concept of 'link' is more complicated than I had
expected. :-(

Another thanks for your trouble and it would be nice if you comment on
Simple DNA draft.

best regards

JinHyeock

On Jan 11, 2008 2:40 PM, Hemant Singh (shemant) <[email-masked]> wrote:
> JinHyeock,
>
> My humble apologies for jumping in late on this thread. Let me explain
> why the cable deployment is good and not as messed up as one might think
> - I will explain the details. I don't consider the cable network as a
> multi-link network. It's more of a point to point network. Here is why.
>
> The cable router, which is also called a CMTS (Cable Modem Termination
> System), has a property of a virtual bundle network interface. CMTS is
> also a DHCP relay agent. The L3 virtual network interface aggregates a
> bunch of physical L2 cable interfaces. For example, a Cisco CMTS router
> can have 40 cable network L2 interfaces - each of the 40 L2 cable
> interface can serve about 5000 homes. It doesn't make sense for the
> cable operator to assign L3 IP addresses to all of the 40 cable network
> interfaces - it's a configuration hassle for operators. That is where
> the L3 virtual bundle interface comes into play. One can aggregate say,
> 20 cable interfaces, under one bundle interface on the CMTS router. So,
> now the CMTS with 40 cable network L2 interfaces has only two L3 virtual
> bundle interfaces to which IP addresses and subnets are assigned. For
> IPv6, every bundle interface on the CMTS is one link. Yes, the multiple
> L2 cable interfaces represent physical links going to various homes, but
> the single L3 virtual bundle interface serves all the homes.
>
> Further, the physical connectivity of the cable deployment is such that
> no host behind a cable modem can communicate directly to another host
> behind another modem. All host traffic has to go through the CMTS
> router. Since hosts send traffic directly to router to communicate with
> any other host, that is why cable deployment if always off-link for both
> IPv4 or IPv6. That is also why the cable model maps to a point to point
> model.
>
> That is why cable folks were looking at ND to see how to specify
> off-link in ND for CMTS router. After going thru the ND RFC's we
> realized there was ONLY one way one could signal off-link in ND. That
> was by not sending any PIO (Prefix Information Option) in RA.
>
> When I get the time, I will review DNA simple draft as well and send my
> comments.
>
> Kind Regards.
>
> Hemant
>
> -----Original Message-----
> From: JinHyeock Choi [mailto:[email-masked]]
> Sent: Thursday, January 10, 2008 6:54 PM
> To: Wes Beebee (wbeebee)
> Cc: Bernard Aboba; [email-masked]; Hemant Singh (shemant)
> Subject: Re: [DNA] DNAv6 Review from Mobopts
>
>