Subject: [DNA] Comments on draft-narayan-dna-hosts-bcp

From: Erik Nordmark <[email-masked]>
Date: Mon, 07 Mar 2005 15:31:25 -0800

Since nobody is paying attention to jabber, I can't contribute in real time.

I have rather serious concerns about basing the hosts BCP draft on the 
text in this draft for several reasons.
The high-level ones are:
  - the draft is written to much in a negative form (e.g., make sure you 
take this constraint into account) instead of a list of positive 
suggestions (do X, then Y,)
  - the draft is quite long (partly because it goes into discussing all 
the different constraints)
  - the draft includes suggestions or recommendations which don't seem 
to add much to the capability (such as verifying the routers global 
addresses in addition to the prefixes), which just adds to the complexity
  - the draft includes suggestions or recommendations which are 
optimizations (such as doing a NS/NA exchange with a old default router, 
in addition to the RS/RA exchange), and it would be good to flag these 
as optimizations. Once we have a DNA protocol (with changes on the 
router for fast delivery of RAs etc), such optimizations might actually 
be counterproductive (they might just add load to the link), thus I 
think we should be very careful about recommending this.

So while the draft has useful background information on the constraints, 
but I'd suggest that we start from scratch on writing down the 
recommendations.

I think the list of recommendations is quite short. Here is a guess at a 
list:
  - hosts should implement optimistic DAD (to reduce any DAD-related
    delays)
  - hosts should have a mechanism by which the L2 (the device driver) can
    notify the upper layers when a new L2 connection has been established
    and can send and receive packets
  - hosts which can connect to different L2 connections at the same time
    (for instance, an 802.11 card with two radios which can associate
    with two different APs at the same time) should not hide the fact
    that there are two interfaces but instead expose this to IP as
    separate interfaces
  - hosts should implement CPL
  - when a L2 "link up" notification is received by IP, it should switch
    to optimistic DAD mode since it might have moved to a different link
    where the addresses are not unique
	- This includes sending the MLD join for the solicited node
	  multicast group(s)
	- The RS for CPL is sent in while in optimistic mode
  - should CPL detect that the the host has moved to a different link,
    then any other multicast groups need to be reported using MLD
    (optionally, this can be done while in optimistic mode?)
  - should CPL detect that the host has NOT moved to a different link,
    then the optimistic mode can be turned off

It think that's the minimum useful set for L2 agnostic DNA BCP.

Comments?
   Erik

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 08 Mar 2005 14:52:53 +0200

During the yesterday meeting it was brought up that using prefixes to 
conclude whether a link has changed or not can be problematic in certain 
cases. Can someone confirm whether the following scenario is possible or 
not?

                Router(s) advertising
                  prefixes A and B
                         |
                         |__________X_______ AP2
                         |                  (may use only prefix A)
                         |
                         |
                        AP1
               (may use prefixes A and B)

X marks a box-in-the-middle e.g. a bridge (as mentioned yesterday).

If this is possible, the problem lies here in the fact that if the node 
is first connected to the AP1 it can configure either prefix A or B, and 
if it then moves to AP2 it may only use prefix A even though still 
connected to the same link. Let's assume that a node uses prefix B and 
is connected to AP1. It also knows that the complete prefix list for the 
current link is A and B. It then moves to AP2 and receives an RA, 
notices that the advertised prefix(es) match and thus link has not 
changed. However, it's now using prefix B which is not valid under this 
section of the link.

If this is the case, I'm also curious how you actually prevent a node 
connected to AP2 from not configuring prefix B. Do the box X hassle with 
router advertisements?

Tero

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 09 Mar 2005 01:29:33 +0900

Dear Tero

> changed. However, it's now using prefix B which is not valid under this

Let me clarify the above

When the routers send an RA advertising both A & B, the RA 
will be forwarded both through AP1 and AP2. Right?

If so, that means that AP2 advertise the prefix B which is not 
supported in that (L2) link. I don't think that is valid. 

Best Regards

JinHyeock

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 08 Mar 2005 18:52:20 +0200

Hi JinHyeock,

> supported in that (L2) link. I don't think that is valid.

That is what I would think also, but because I'm not sure I'm asking.

However, I guess the above scenario is possible if X is some sort of a 
firewall. Please, don't ask whether it makes any sense to have such a 
scenario nor who would use such a configuration because I don't have a 
clue. :)

Br,

Tero

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Mar 2005 12:01:45 -0800

> X marks a box-in-the-middle e.g. a bridge (as mentioned yesterday).

I don't see how IPv6/ND can work in such a case, because the router and 
the other neighbors on the link would assume that address resolution 
(NS/NA) as well as IP packet delivery works transparently across the 
IEEE 802 LAN.
So I think this is a broken LAN.

    Erik

---

From: [email-masked]
Date: Tue, 08 Mar 2005 23:17:40 +0000

> connected to AP2 from not configuring prefix B. Do the box X

I believe this scenario *could* be possible but I'm not sure any sane
administrator would do this. If X is a vlan switch and the switch allows
vlan tags to be switched to multiple ports, then you could have a scenario
such as

vlan x = prefix A
vlan y = prefix B

and

vlan x switched to AP2 and AP1
vlan y switched to AP1 (thus only AP1 gets RAs for prefix B)

The only reason I can think of why anyone would do this is if there is some
administrative reason why only AP1 should see prefix B. Perhaps this would
be a restricted prefix that equates to an SSID for a 'top secret' meeting
room.

Cheers,
Martin Dunmore

---

From: Brett Pentland <[email-masked]>
Date: Wed, 09 Mar 2005 13:39:04 +1100

> be a restricted prefix that equates to an SSID for a 'top secret' meeting

I think that in this case, we would detect attachment to the VLANs.  If
we attach to AP2, vlan x, we receive prefix A.  If we move to AP1, vlan
x, we see prefix A, and should through some means decide that we have 
not moved (logically) and our configuration is still valid.

If we move to AP1, vlan y, we see prefix B and through some means should 
decide that we have moved and need to reconfigure.

If we move to AP1 and can receive packets from both vlans x and y at the 
same time, then things get messy.  If we can abstract connections to 
vlans as virtual interfaces, then we can probably treat them separately 
and apply DNA on a per-virtual-interface basis.  If not, then I'm not 
sure how best to deal with the situation.

Any thoughts?
Brett.