Re: [homenet] draft-ietf-homenet-arch-04

[Robert Cragie]

Hi Curtis,

Comments inline, bracketed by <RCC></RCC>

Robert

On 01/10/2012 7:11 PM, Curtis Villamizar wrote:

In message <cc8ee0e5.1a5cb%d.stu...@att.net>
Don Sturek writes:

Hi Curtis,

for any topology....."

where the scope of link local address is only between a single device in
the mesh and its one-hop neighbors (not among all devices in the mesh).

between all devices in a single mesh subnet.

On the topic of "link local on each subnet and a routing protocol works In using 6LoWPAN with ROLL (route over), you end up with a mesh network In a 6LoWPAN/ROLL topology, we need a ULA to allow routable communications Don

Don,

The "subnet" is meant in IETF terms, not ITU subnetwork.  The subnet
is therefore anything link local by definition.

<RCC>Not in the case of RPL or MANETs. This is a multi-link subnet where routers within the subnet are L3 forwarders (aka "route over").</RCC>

   A 6LoWPAN node can
get a GUA and use the GUA (or link local address) of a router as a
default route.  If the 6LoWPAN device needs only site connectivity
then it can use the link local address for everything.

<RCC>Again, not true in RPL or MANETs. As Don points out, in a RPL/MANET network, link local means your one-hop neighbors only.</RCC>

If a routing protocol is in use and is using link local based host
routes, then a router must fake the DAD collision if a duplicate is
found anywhere within the site.  If a multiple ULA are used, one per
subnet, then DAD is only relevant to the subnet.  A router should pick
a ULA prefix that is not already in use elsewhere in the site.

<RCC>In the multi-link subnet, typically a single ULA or GUA would be used for the whole subnet including the routers. Multihoming may be necessary depending on external connectivity.</RCC>

An extremely low probability race condition exists, but it is a race
condition among routers with multiple routers picking and advertising
the exact same ULA prefix in the routing protocol very nearly
simultaneously (within LAN flooding interval).  A wait and backoff can
solve this even though it is a miniscule probability.

A mesh in IETF terminology is by definition multiple subnets.  A
subnet is by definition link local.

<RCC>Again, not according to RPL and MANET protocols. There does seem to have been some discussion on this which probably needs to be resurrected (see RFC 4903).</RCC>

Curtis

On 9/30/12 3:36 PM, "Curtis Villamizar" <cur...@occnc.com> wrote:

In message <cc872d11.1a2ee%d.stu...@att.net>
Don Sturek writes:

Hi Robert,

1)  Ideally, it would be great if a single authorizatative device
existed
in the home providing DHCPv6 server services (if supported) and prefix
delegation.

multiple subnets, each possibly acting as a DHCPv6 server within their
own
subnet and also providing their own ULA prefix.

setting
where IT support does not exist.

One more point touched on in your note below: One challenge in the description below is having multiple routers on We certainly don't want to further confuse address assignment in a Don

We want things to "just work" witb no config.  Link local on each
subnet and a routing protocol works for any topology.  ULA just allows
summarization of subnets in the routing protocol, such that host
routes are not needed (though not a big deal if host routes are used
in a homenet).

This would "just work" when using link local or ULA.  How to subdivide
a GUA prefix among the subnets is another issue.

In principle, though I know of no proposals to do this yet, the set of
GUA that are available from one of more routers with a provider link
could be coordinated via the routing protocol (for example, using a
new OSPF Opaque LSA).

Curtis

On 9/25/12 1:57 AM, "Robert Cragie" <robert.cra...@gridmerge.com> wrote:

So let's tweak Curtis' sequence slightly:

What every host does is:

  if it has no MAC:
    pick a random link local address
  else
    use the MAC to create a link local address
  run DAD to make sure no one else has same address

  send a RS

  if it gets RA
    use the RA prefix for SLAAC
  else
    time out and don't bother with SLAAC; can only use link local

address

then hopefully the host also does the following:

  send DHCPv6 client request

  if response
    it has yet another address to pick from if it got one using SLAAC
  else
    time out and get nothing from DHCPv6

This should work fine for legacy APs where everything is bridged
underneath it. Where it gets interesting is in the case of cascaded
subnets behind a router connected to an ISP, where one or more of those
subnets may be a mesh network comprised of mesh routers and hosts. I am
not quite sure how ULAs and DHCPv6 would work in this case as there are
limitations as far as I can see (although I accept I probably have a

bit

more reading to do on the subject).

Robert

On 25/09/2012 5:45 AM, Curtis Villamizar wrote:

In message <cc866762.1a28f%d.stu...@att.net>
Don Sturek writes:

Hi Curtis,

I think the difficulty is each device cannot "use the MAC to create

a

ULA
address".  Some authoritative device in the network (eg, the AP)

must

create the ULA prefix.  If a ULA prefix is not present because the

AP

is a
legacy device not capable of providing a ULA prefix, the STA devices
must
use link locals only.

Don

Don,

You are right about there being nothing to generate the ULA prefix in
your example.  My mistake.

But it doesn't change anything.  If the AP is a dumb bridge and there
is no router of any kind, then link local addresses are perfectly
fine.  There is only one subnet in that example, and ULA is not
needed.  That was the example you gave.

Your example had no router just an old AP that acted as a bridge,
therefore nothing to generate any sort of RA.  If there is a router
and no GUA prefix (which is not your example, but a useful example),
then ULA can be used.  The only RA that is seen is the RA providing a
ULA prefix which the router can generate.

I did say that the possibility of having to subdivide a /64 only
exists for GUA.  If a router exists which gets a GUA from a provider,
and there are more subnets than the prefix length can support the two
options are the ones listed below.  (Search for --or--).

Curtis

On 9/24/12 6:52 PM, "Curtis Villamizar" <cur...@occnc.com> wrote:

In message <cc864fc3.1a27f%d.stu...@att.net>
Don Sturek writes:

Hi Curtis,

address
assignment they do today (ie, manual assignment and DHCP).  I

I would expect most Wi-Fi AP manufacturers to support the same

would

also expect as more IPv6 deployments happen that SLAAC will also

be

supported (and, yes, even for GUA).

For the types of devices which will be added to Wi-Fi networks in

the

future (eg, headless devices like appliances, thermostats, etc.)

that

the preferred address assignment will be SLAAC and DHCPv6 (and,

yes,

I
purposely did not remove SLAAC.....)

Don

Don,

We seem to be talking past each other so let me again try to be

clear.

What every host does is:

   if it has no MAC:
     pick a random link local (not ULA) address
   else
     use the MAC to create a ULA address
   run DAD to make sure no one else has same address

   send a RS

   if it gets RA
     use the RA prefix for SLAAC
   else
     time out and don't bother with SLAAC

then hopefully the host also does the following:

   send DHCPv6 client request

   if response
     it has yet another address to pick from if it got one using

SLAAC

   else
     time out and get nothing from DHCPv6

Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server
the address that it already has (from SLAAC).

If as in the case of your Wi-Fi with a bridging AP example, there

is

no router to give it an DHCPv6 the link local or ULA addresses are
still there and still usable.  There is also no router to give it

an

RA response so it has no SLAAC assigned address and no DHCPv6

assigned

address.

That is the end of your example.

If there is a router then there is something that can hand out a

RA or

DHCPv6 response.

In the case were there exists multiple subnets and the CER has been
granted a /64 (or too few /64s to handle the number of subnets),

then:

   it can use RA with /64 on some subnets and give them GUA

addresses

   and some subnets have no access outside the homenet

   --or--

   it can not use RA (and therefore prevent SLAAC from being used)

and

   hand out DHCPv6 addresses and make use of prefixes longer than

/64.

   This prevents the use of CGA but get connectivity to the entire
   homenet.

If every consumer oriented provider is willing to allocate prefixes
shorter than /64 on request to home users, then the above situation
never occurs.  If it does, my argument is that the second option

above

is better than the first.

Curtis

On 9/24/12 5:11 PM, "Curtis Villamizar" <cur...@occnc.com> wrote:

In message <5060bdc7.6020...@freedesktop.org>
Jim Gettys writes:

On 09/24/2012 03:17 PM, Don Sturek wrote:

Hi Curtis,

Here is the use case:
1)  Customer has a legacy AP in their house
2)  Customer brings home new devices supporting IPv6 (which are

designed

to communicate only with other IPv6 based devices in the home)
3)  The only way these new devices can communicate is through

address

assignment using SLAAC and then some discovery method the two

new

devices

support (without support from the AP).  Here these devices are

assuming

bridging through the AP......

And since current legacy AP's all bridge, we win (even though we

need to

route in the future).

Jim,

The point was how do you get local IPv6 within the home with the
legacy AP that does only IPv4 and just does bridging of IPv6.

First

of all you have no subnets.  There is no CER to do DHCPv6.

In this case you use link local or if everything has a MAC you

can

use
ULA based on the MAC addressses.

Placing a requirement that every customer who buys a new IPv6

device,

intended to communicate only with other IPv6 devices in the

home,

will

require a forklift upgrade of a deployed network in order to

work

will not

be popular.

Good point.

But invalid.  The use case Don gave would still work fine.  Only

GUA

addresses are affected.

I loathe DHCP (of any sort) *for basic address assignment,

anyway*

in
the home environment.

flaky
home network  for several months, before realising I had a rogue
DHCP
server somewhere on my network (from wireshark).  I then had to
take

The loathing comes from the exquisite pain of suffering with a

the

mac address, figure out who may have manufactured some device

from

that

information, and finally figured out the little VOIP ATA

adaptor I

had

been given liked to do DHCP.

It did DHCP on the *WAN side*?  You didn't put the rest of your
network behind the VOIP box on the LAN side I hope.

This was by far the hardest debugging I've had to do in my home

network

in normal operation.

This is well beyond normal home debugging capability of

consumers.

              - Jim

We all have plenty of crappy IPv4 product horror stories.  My

VOIP

phone locked up now and then and I figured out that if the call
lasted
longer than the DHCPv4 lease, then it lost the least because it
didn't
try to renew it.  Not only did the call drop, but the device

locked

up.  The first solution was to reboot it now and then.  The

answer

was
to configure a fixed address.  I was lucky to figure it out

before

my
wife threw the phone through a window.  For all I know a later
firmware upgrade might have fixed it.  VOIP might be more

popular if

VOIP phones under $600 worked reasonably well.

Both nice stories, but both are DHCPv4 related and have nothing

at

all
to do with SLAAC.

Curtis

Don




On 9/24/12 11:49 AM, "Curtis Villamizar" <cur...@occnc.com>

wrote:

In message <cc84f8f1.1a1c4%d.stu...@att.net>
Don Sturek writes:

Hi Curtis,

SLAAC not working is a major problem. Don

Don,

Why?  This is an assertion without basis as far as I am
concerned.
Except CGA there is nothing that breaks without SLAAC.  Joel

brought

up ILNP in private email, but I beleive ILNP can also work as

the

constraints in ILNP are in the ILNP identifier which is not

the

same

as the interface address in ILNP for which there is no
constraint.

I have subnets running fine using a few /112 allocated from

within a

/64 with fixed addresses on rack mount hosts and desktops and

DHCPv6

for dynamic allocations for laptops.  It works fine.  Link

local

addresses are all that is needed to get DHCPv6 to work.  No

host

ever

receives a RA since my routers won't give them one, so no host

ever

tries to generate an address using SLAAC.  The only

constraint is

that

any host connecting to my Ethernet or wireless must run a DHCP

client

and if they want an IPv6 GUA must run a DHCPv6 client.  DHCPv4
and
DHCPv6 servers are available in every subnet except one GbE

subnet in

the rack and to a few hosts in my home office.

So as far as I am concerned we have an assertion that no

SLAAC is

a

problem and existance proof that it is not.  Beside CGA and

requiring

that hosts run DHCPv6 if they want an IPv6 GUA, what can I not

support

on these /112 subnets?

Curtis

On 9/23/12 4:09 PM, "Curtis Villamizar" <cur...@occnc.com>
wrote:

In message <505e83f6.3030...@joelhalpern.com>
"Joel M. Halpern" writes:

Since you invited flames...

The argument on /64 as the longest prefix is not that it is

magically

unnatural.
Rather, it is that there are a number of current and

evolving

protocols

that depend upon that /64.  The obvious example is that

SLAAC

does

not

work if subnets are longer than /64.

The rules in this regard are written into approved RFCs.

If

homenet

wants to change that, it really needs to go to 6man with a

strong

case.

    (for point-to-point inter-router links this was recently

relaxed.

At the same time, andy operator who insists on giving

homes a

/64

is

being inappropriately restrictive.  Homenet should say

that,

rather

than
trying to change the IPv6 architecture.

Joel

Yours,

Joel,

I don't consider your email a flame at all.  Thanks for

responding.

SLAAC (which I am not at a fan of) won't work but DHCPv6

will

so

IMHO

no loss.  CGA also won't work but then again I've also never

been a

fan of security half measures.  Yes anti-spoofing without

prior

exchange of a key is nice, but no reasonable authorization

could be

based on CGA without also exchanging some sort of key or

cert

and

at

that point the CGA as a public key is redundant.

If SLAAC and CGA are the only things that break *and*

providers

do

hand out prefixes that are too small, then /64 prefixes will

have

to

be subdivided.

So a question for you is what else if anything will break?

I also understand that you are suggesting that this be

taken to

6man.

That is a good suggestion.

Curtis

On 9/22/2012 11:30 PM, Curtis Villamizar wrote:

    12.  This is sure to be controversial.  I pointed out

that

using

         subnets longer than /64 is OK as long as they are

not

leaked

         into global routing.  Please read the text and
changes

before

         exploding on this topic.  It may be necessary to

subnet a

/64

if

         that is all a provider will give you and you need

subnets.

It

         does work and it is no more unnatural than
subnetting a

class-A

         network would be in 1990.  It means using DHCPv6

and

not

using

         RA prefixes for GUA (otherwise SLAAC

implementations

would

         likely try to use the whole bottom 64).

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet