Re: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs)

[gabriel montenegro <[e-mail]>]

GARP/GMRP is not widely deployed, and seems to be obsoleted at the IEEE already.
RFC 4541 (MLD snooping) is the deployed solution, as Max already discussed 
in the November meeting:

    http://www3.ietf.org/proceedings/06nov/slides/16ng-4/sld7.htm

Notice that the last bullet mentions that no ND changes are required, so 
a future revision of the IP-over-ETH-CS draft will have much simpler ND-related
text.

A good reference in this respect is:
   2.7.2.  Host/Router Flooding Reduction in
   http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-07.txt
To point out that solutions exist, of which RFC4541 is the most widely deployed.

-gabriel

----- Original Message ----
From: Alexandru Petrescu <[e-mail]>
To: "Premec, Domagoj" <[e-mail]>
Cc: [e-mail]; [e-mail]
Sent: Tuesday, January 9, 2007 2:02:04 PM
Subject: Re: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs)

Hi Domagoj, thanks for the email, skipping the parts we agree...

Premec, Domagoj wrote:
>>>> - Any reference or description of "Relay DAD"? there are 
>>>> earlier occurrences
>>> Relay DAD is described in 2.2.2.3. Are you just pointing out that
>>>  Relay DAD is mentioned before 2.2.2.3, so the explanation should
>>>  also be moved to the first occurance of Relay DAD? "Relay DAD" 
>>> and "ND Relay" are terms also used in 
>>> draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
>> 
>> I would point out to more than just moving the definition text next
>>  to the first use.
>> 
>> ND is defined in rfc2461 and DAD in rfc2462.  None of these 
>> documents defines what a "Relay ND" or a "Relay DAD" would do.  An
>>  IP machine 'relaying' ND packets from left to right, across links,
>>  instead of forwarding or routing them needs to be specified
>> clearly and separately I believe, provided there's an identified
>> need.
>> 
>> For example, the draft  says:
>>> Relay DAD means that the Neighbor Solicitation message used in 
>>> DAD process will be relayed only to the MS which already has 
>>> configured the solicited address as its own address (if such MS 
>>> exist at all).
>> In one sense, this is what DAD does already (not Relay DAD). 
>> RFC2462:
>>> Before sending a Neighbor Solicitation, an interface MUST join 
>>> the all-nodes multicast address and the solicited-node multicast 
>>> address of the tentative address.  The former insures that the 
>>> node receives Neighbor Advertisements from other nodes already 
>>> using the address; the latter insures that two nodes attempting 
>>> to use the same address simultaneously detect each other's 
>>> presence.
>> So I could suggest removing the word 'Relay' from the draft text, 
>> just leave "DAD", and all would be fine.
> 
> No, relay DAD is no ordinary DAD. The standard DAD procedure assumes
>  that the DAD solicitation is delivered to all the nodes using the 
> same prefix. Relay DAD delivers the DAD solicitation only to the node
>  that already owns the address being verified.

Not very sure about that.  The DADing NS is sent to an IP solicited-node
multicast address.  Not all nodes in the subnet join that address, only
the ones whose last 24bits of MAC address match the Tentative Address.

The DAD procedure doesn't assume the DADing NS is sent to all nodes
multicast address (with link-scope). rfc2462 5.4.2: "IP destination is
set to the solicited-node multicast address of the target address."  The
IP dst address would be FF02:0:0:0:0:1:FFXX:XXXX (X: last 24bits of MAC
address).  The link-layer dst multicast address would be
33-33-FF-XX-XX-XX I believe (X: last 24bits of MAC address, for IPv4
it's different: 23bits).

If one desires to deliver the DADing NS only to one particular node (and
not to a group) then one would put the full IP address in the dst, and
the full MAC address in the link-layer dst.  And this behaviour is not
specified by DAD (not sure whether it's forbidden, but it's not spec'ed
in rfc2462).

>> In another sense, reading the draft text suggesting to send the NS 
>> to only some MSs (maybe another criteria than joining an address) 
>> makes think that it may defeat the DAD's main goal.  What happens 
>> if some MS autoconfigures an address that conflicts with the one in
>> NS and that MS doesn't see that NS.
> 
> This must not happen. It is the responsibility of the bridge (the 
> authorative address cache) to deliver the DAD solicitation to the 
> right MS (the one that already owns the address being verified).

Ok, I think we have identified a good responsability for the bridge, and
this is inline with my understanding of bridge making link-layer
multicast work ok.

This bridge could also implement 802.1D and 802.1Q.  More precisely
maybe the GARP Multicast Registration Protocol (GMRP).  With this
link-layer LLC protocol, a GARP participant declares to another about
the group it wants to receive.  This happens with LLC PDUs (not IP
packets).  I think, no?

In this case the BS would not forward the DADing NS to the nodes that
haven't joined the link-layer solicited node multicast address.

So if the BS does that then bandwidth wouldn't be wasted and waking up
idle modes wouldn't be, no?

>> Related to 'Relay' in this context is the concept of 'proxy ND' 
>> whereby a node would do ND  on behalf on another node. This is 
>> partly defined in ND rfc2461 and largely used by a Mobile IPv6 HA 
>> rfc3775.  Just wanted to mention them.
> 
> The intention of the relay DAD is to save the radio resources. When a
>  host sends a DAD solicitation, 802.16 MAC will deliver it to the BS.
> 
> 
> 
Ok.

> Normal behavior as per RFC 2461 would be that the DAD message is 
> delivered to all MSs sharing the same prefix.

Not to all, just those that joined the group (small, maybe 1-sized) of
solicited node mc address.  No?

> But many of the MSs may be in the idle mode, meaning that the 
> delivery of the DAD message would incur paging and wake up from idle
>  mode, in addition to radio bandwidth necessary to transfer the DAD 
> solicitation itself.

Yes, two things: avoid waking up and avoid unnecessary bw consumption.

To avoid consuming bandwidth the BS shouldn't send the DADing NS to all
nodes under it.  This can be achieved with a link-layer multicast
protocol (not IP) and normal DAD.

To avoid waking up the idle node, the SS Eth drivers (under a BS not
doing that multicast link-layer stuff) can avoid putting the received
packet to the kernel stack, based on the local driver table it maintains
about the link-layer multicast groups it listens too.  Most Eth drivers
on a SS are able to filter what they receive (not deliver to IP stack).
 Some drivers are sensitive to packets received on Eth and will wake up
the node for any packet, some are more picky.

I agree though that _if_ DADing NS were sent to all-nodes multicast
address then it would potentially involve waking up all those who joined
that group, thus all nodes in a subnet.

> In relay DAD approach, the bridge (from figure 5) is aware of all 
> attached MSs and their IP addresses (authorative address cache). 
> Using this knowledge, the bridge can deliver the DAD solicitation 
> only to the MS that has already configured the address being verified
>  as its own address. And this MS will then defend its address.

Yes, this is what normal DAD would do too (not Relay), provided the node
joined that solicited-node address.  No?

The bridge should be able to do Ethernet multicast and I believe many
are, no?  Otherwise in a hierarchy of bridges all broadcasted packets
would be seen by everyone, and this doesn't happen in the wired world.

> Yes, this is similar to HA performing proxy ND on behalf of the 
> mobile node. And the bridge may indeed defend the verified address on
>  behalf of another node (which owns the address being verified). But 
> it is my understanding that such (proxy ND) approach would't work 
> with secure ND, that's why the bridge, in case of address conflict, 
> will relay the DAD solicitation to the MS so that the MS itslef can 
> defend the address.

Ah I see!  But Relay ND would have its own issues with SeND - right?

I think one can build attacks on both proxy ND and on 'Relay' ND.

> I-D draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt also 
> mentiones relay DAD. It does provide some additional details. We 
> should probaby define relay DAD just in one document and then refer 
> to it form other documents.

Yes, Relay ND looks as a new functionality that deserves separate
documentation.  For one it's obviously different IPv4 (Relay ARP?)
than IPv6 at least because (1) IPv4 doesn't require the use of
link-local multicast addresses and (2) address duplication detection for
IPv4 link-local addresses is different than DAD.  So I would suggest
separation that the IPv6-over-ETH draft in two: IPv6 and IPv4.  And the
Relay DAD draft too in two: Relay DAD and Relay ARP.

For Relay DAD, if there's enough energy and need to document as a
specific functionality (like proxy ND) then I think it needs
requirements and goals too.  Otherwise it could be documented as an
informational feature that has probably been implemented(?) or needed by
an SDO(?).

Thanks,

Alex


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng