Subject: [Autoconf] eg NBMA links...

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 09 Nov 2009 10:10:33 +0100

Eg NBMA links doesn't mean AUTOCONF, so the current text in RFCs 
excluding DAD in eg NBMA links doesn't apply.

In AUTOCONF we don't know what kinds of links we use. (so no NBMA, no 
not NBMA).

Alex

---

From: Paul Lambert <[email-masked]>
Date: Wed, 11 Nov 2009 11:23:40 -0800

Hello,

As a occasional lurker ... I'm hoping someone could point me to the most applicable draft document to support a very near term application of this groups work in consumer devices.  The basic problem statement is:

 - environment is 802.11 IBSS with security
    - multicast is not available to all devies until 
      after they have been "discovered" in some other manner
 - provide some form of accelerated discover for the L2 
   addresses in the network
 - Assign unique IPv4 addresses
 - Optionally assign unique IPv6 addresses

Paul

PS - I'm only an occasioanl lurker, and in attempting to read the mail list and drafts I could not get a clear view of an answer ... so please excuse this post if it's a naïve question

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Nov 2009 20:43:24 +0100

Paul Lambert a écrit :
> Hello,
> 
> As a occasional lurker ... I'm hoping someone could point me to the 
> most applicable draft document to support a very near term 
> application of this groups work in consumer devices.  The basic 
> problem statement is:
> 
> - environment is 802.11 IBSS with security - multicast is not 
> available to all devies until after they have been "discovered" in 
> some other manner

You mean link-layer multicast?  Or IP multicast?

I am asking because if there is no link-layer multicast then IPv6 as it
is won't work in no way.  I am not sure what you mean by "discovered in
other manner".

> - provide some form of accelerated discover for the L2 addresses in 
> the network

In IPv6, maybe tweaking the ND timers will do it accelerated. (not sure
what you mean by accelerating, what is slow?).

> - Assign unique IPv4 addresses

If you need IPv4 link-local addresses, they're already there.

> - Optionally assign unique IPv6 addresses

Well, if you need IPv6 link-local addresses on this setting - they're
already there.

If you need global addresses then is it feasible to configure them
hardcoded on each device?

Or adminstratively decide that _one_ of the devices is _the_ Router
sending them an RA and being the DHCPv4 Server, and hardcode the
prefixes in dhcpd.conf and radvd.conf.  Probably the Router is
the same machine which connects to the Internet too?

What do the others think?

Alex

> 
> Paul
> 
> 
> PS - I'm only an occasioanl lurker, and in attempting to read the 
> mail list and drafts I could not get a clear view of an answer ... so
>  please excuse this post if it's a naïve question 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: Paul Lambert <[email-masked]>
Date: Wed, 11 Nov 2009 12:13:41 -0800

> From: Alexandru Petrescu [mailto:[email-masked]]
...

> You mean link-layer multicast?  Or IP multicast?

Link - with encryption, AES-CCMP does not allow a common group key, so broadcast/multicast is not available until after a device has been discovered and the per-STA multicast keys are exchanged.  Of course - IP layer will also not work until have the network has bootstrapped.

> what you mean by accelerating, what is slow?).

Accelerated in this context is looking for individual devices to give hints about possible neighbors.  At L2, you could wait for many beacon periods and discover most of the peer devices (except a few hidden or in power save or temporarily absent).  Beacons are not reliable, active probing is not viable, we're already starting to use Public Action frames to discover "awake" or "selected" devices.  

Basically - every device needs to store what it thinks is the composition of the network and share this when requested.  At a minimum, this is L2 membership.  It could also include L3 addresses explicitly or implicitly.

There are some proprietary implementations of the above ... a standard would be nice.  I'm currently writing such specifications in L2 organizations (Wi-Fi Alliance).  I'll likely extend it to some L3 discovery if there is nothing available from this working group.

> If you need IPv4 link-local addresses, they're already there.

Additional signaling is required to ensure address uniqueness. IPv4 link-local addresses do not work as defined for multicast challenged networks.

So there is not an answer.

Note - this is causing Link Local addresses to NOT be used in some BSS applications also.  Not all devices will be available at any one time.  Mobile networks are not consistent and prevent multicast based discovery.

> hardcoded on each device?

Humm ... of course ... Thanks for the reminder :-)  I think the groups I'm working with never consider this ... IPv4 is here now and we never get around to future proofing by getting IPv6 and IPv6 addresses.  These are L2 groups ... so there has not been much in L3 definitions or planning.  It looks like I may need to change this ... I'll take in some IPv6 requirements and see what happens.  

I really do appreciate the reminder ... we're right at a point where at least having some L2 negotiation ability to indicate the L3 type will be of value (I believe this in 802.11u or 802.11v).  I'll work to get this inserted.

> the same machine which connects to the Internet too?

Wi-Fi Direct is doing something like this and needs to have DHCP.  It does create real pro0blems for fail-over and "real" mobility (i.e. unpredictable coming and going of devices)

IBSS solutions still need a IPv4 link local address mechanism that works ... likely by device caching of peer l2 addresses.

Regards,

Paul

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 12 Nov 2009 07:01:50 +0900

Hello Paul,

You could read our workgroup draft. Any comment is appreciated.
http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-00.txt

With having guaranteed unique MAC addresses, IPv6 addresses are easy to 
configure. Link-locals should be there, but does not provide multi-hop
connectivity. If needed, you could use ULA prefix, this can be generated
locally on each node. For globals, this WG does not have a solution yet, 
but there are a number of proposals.

When running NHDP on P2P link to the beaconing nodes, you will get
fast neighbor learning. If all nodes set up such channels, the beaconing
nodes are aware of their 2-hop neighbors. And then the next step, the
beaconing
nodes try to set up NHDP to all their 2-hop neighbors. This will make the
local 2-hop topology tables pretty good populated. Adjustments on NHDP
could be needed, to make this work.

Teco.

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Paul Lambert
>Verzonden: donderdag 12 november 2009 5:14
>Aan: Alexandru Petrescu
>CC: [email-masked]
>Onderwerp: Re: [Autoconf] Ad Hoc Wireless Address Assignment
>
>
>
>Link - with encryption, AES-CCMP does not allow a common group key, so
>broadcast/multicast is not available until after a device has been
>discovered and the per-STA multicast keys are exchanged.  Of course - IP
>layer will also not work until have the network has bootstrapped.
>
>>
>Accelerated in this context is looking for individual devices to give
>hints about possible neighbors.  At L2, you could wait for many beacon
>periods and discover most of the peer devices (except a few hidden or in
>power save or temporarily absent).  Beacons are not reliable, active
>probing is not viable, we're already starting to use Public Action
>frames to discover "awake" or "selected" devices.
>
>Basically - every device needs to store what it thinks is the
>composition of the network and share this when requested.  At a minimum,
>this is L2 membership.  It could also include L3 addresses explicitly or
>implicitly.
>
>There are some proprietary implementations of the above ... a standard
>would be nice.  I'm currently writing such specifications in L2
>organizations (Wi-Fi Alliance).  I'll likely extend it to some L3
>discovery if there is nothing available from this working group.
>
>>
>Additional signaling is required to ensure address uniqueness. IPv4
>link-local addresses do not work as defined for multicast challenged
>networks.
>
>Note - this is causing Link Local addresses to NOT be used in some BSS
>applications also.  Not all devices will be available at any one time.
>Mobile networks are not consistent and prevent multicast based
>discovery.
>
>>
>Humm ... of course ... Thanks for the reminder :-)  I think the groups
>I'm working with never consider this ... IPv4 is here now and we never
>get around to future proofing by getting IPv6 and IPv6 addresses.  These
>are L2 groups ... so there has not been much in L3 definitions or
>planning.  It looks like I may need to change this ... I'll take in some
>IPv6 requirements and see what happens.
>
>I really do appreciate the reminder ... we're right at a point where at
>least having some L2 negotiation ability to indicate the L3 type will be
>of value (I believe this in 802.11u or 802.11v).  I'll work to get this
>inserted.
>
>>
>Wi-Fi Direct is doing something like this and needs to have DHCP.  It
>does create real pro0blems for fail-over and "real" mobility (i.e.
>unpredictable coming and going of devices)
>
>IBSS solutions still need a IPv4 link local address mechanism that works
>... likely by device caching of peer l2 addresses.
>
>Regards,
>
>Paul
>
>
>>
>[email-masked]
>https://www.ietf.org/mailman/listinfo/autoconf

---

From: Paul Lambert <[email-masked]>
Date: Wed, 11 Nov 2009 17:20:34 -0800

Thanks Teco,

Some good guidelines ... the /32 subnet clearly helps the scenarios I'm describing.  Now ... on Link Local, I agree that a locally generated LL address that is subsequently checked solely for uniqueness using multicast techniques should be avoided.  

You may want to glance at: http://www.wi-fi.org/news_articles.php?f=media_news&news_id=909

Wi-Fi is evolving rapidly ... the groups that are doing this work are not very fluent in L3 addressing issues.  Some odd scenarios might start to appear with these new technologies - like the same L2 address on multiple BSSs.  

The guidelines are good, but a specific protocol solution is required to provide unique IPv4 addresses in a distributed manner.

My planned approach will likely be to:

Have every device keep track of peers - and share in a distributed manner
	1) On first enrollment between two devices the master (registrar)
         picks it's IP address and gives the list of network MAC addresses
         and IP addresses to the new enrollee ... 
      2) Network size is limited and addresses are discarded using LRU rule
      3) As a STA contacts other STA for the first time (post WPA), 
         the same information is exchanged between the pair of devices.
      4) Local table of peers is updated based on this exchange
      5) Multicast table validation might be viable (optional) after a 
         STA becomes fully associated with a set of peers and 
         limited multicast is possible.

Regards,

Paul

Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141

> -----Original Message-----
> From: Teco Boot [mailto:[email-masked]]
> Sent: Wednesday, November 11, 2009 2:02 PM
> To: Paul Lambert
> Cc: [email-masked]
> Subject: RE: [Autoconf] Ad Hoc Wireless Address Assignment
> 
> Hello Paul,
>