Re: [homenet] walled garden DNS

[Peter Koch]

On Mon, Oct 10, 2011 at 01:06:23PM -0400, Michael Richardson wrote:

>   example.com   NS reachable by the world.
>   garden.example.comNS pointing to  record, where IPv6
> address is only reachable from garden.
>   television.garden.example.com returned from
> garden.example.com name server (above)
> 
> This solution works perfectly in IPv4 land, but due to lack of IPv4

it works, but nowhere near perfectly. Whenever a querying system
changes its intended name space (resolution context) from $local
to the global one, resolution of names in garden.example.com
will just time out. Encoding this user experience in the design looks
like a suboptimal choice to me.
For resolution from the inside, you'd likely be dependent on access
to the external delegation, which may not be feasible, either.

> It seems to me that we just don't need anything else in IPv6, except
> easily *available* non-connected PI address space (whether it's ULA-C,
> some recognized part of 2000::/3, or an entirely new space).

While ULAs would "reduce" collisions, the general issues would be the same
as with RFC1918 space.

A single "local" context won't be enough.

-Peter
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jari Arkko]

Home routers would also have MAC addresses, but again, if we need a 32-bit 
quantity then shortened 48/64 bit identifiers may (theoretically) have 
collisions.

That being said, if the home routers have to discover their IPv6 prefix through 
a protocol and store it in flash, they could probably do so also for a router 
ID. Unless there was some chicken and egg problem that required the router ID 
for all this discovery to work...

Jari

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

Re: [homenet] Homenet Architecture & Interim Meeting

[james woodyatt]

On Oct 10, 2011, at 19:45 , Curtis Villamizar wrote:
> 
> All of this is only true for IPv4 but not for IPv6.

I wasn't talking about IPv4 at all.  My comments are relevant in a world 
entirely comprising IPv6-only service providers.  The IPv6 Internet will be 
saddled with all of the problems of the IPv4 Internet with respect to devices 
on homenets having to beg the gateways to allow inbound packets from arbitrary 
remote destinations.  It has nothing to do with NAT, and everything to do with 
firewalls and stateful filters.


--
james woodyatt 
member of technical staff, core os networking



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

Re: [homenet] Homenet Architecture & Interim Meeting

[Curtis Villamizar]

In message <34789394-ddbf-4ca6-85ef-9449badbb...@apple.com>
james woodyatt writes:
 
> On Oct 10, 2011, at 08:51 , Michael Richardson wrote:
> > 
> > It does break the *I*nternet model: the one where the ISPs control
> > everything like the telcos did before, and I need to beg to be allowed
> > to receive SYN packets.  Why do I care if it breaks the business plans
> > of some ISPs?   
>  
> I hate to break the news to you, but it isn't the ISPs that are making
> you beg to receive a SYN packet from anywhere on the Internet.  It's
> the home gateway vendors, who are following the advice of RFC 4864 to
> implement stateful default-deny simple security mechanisms, and who
> follow the advice of myriad other 'experts' who insist that these
> functions be enabled by default.
>  
> Shorter james: it's your residential subscribers who insisting that
> your devices need to beg for permission to receive inbound SYN packets
> from arbitrary remote addresses.
>  
> The IETF is in the process of specifying a protocol to let you beg for
> incoming packets, c.f. I-D.ietf-pcp-base.  I wish you all the luck in
> the world convincing the average home networking gear buyer that they
> shouldn't need any of this craziness.  Sincerely.  I tried that.  Been
> there, done that, got the T-shirt, ended up buffing the car with it,
> donated the car to charity when the car wore out... in other words, I
> am done struggling against what you call "the Internet model" because
> from my perspective that's like to trying to bail out San Francisco
> bay with a tea cup.  Have fun storming the castle though...


All of this is only true for IPv4 but not for IPv6.

If you need a SYN from outside, then you need a globally routable
address and then practically speaking you need IPv6.  The most simple
solution is 6to4 but that means replacing the border router if it
doesn't support 6to4.

The other way is to accept the rfc1918 address you got from the NAT
and TCP tunnel through the NAT.  For an electrical meter with
extremely low throughput needs and very high delay tolerance, this
seems easy enough.  The meter simply need to know the IP address of
its electrical transmission provider.  If that IP addres is not
configured right at installation, the power never comes on and someone
would notice.  The electrical transmission provider can then provide
an IPv6 address and a gateway to IPv6.  The cost is a tiny flow of TCP
keepalives but if the ISP complains, tell them to support IPv6.

It is a shame that you can't get a SYN from outside into a home
network that is behind an IPV4 only NAT44, but use of NAT is not a
situation that the IETF encouraged.  We can't change that so we can
only try to move forward on a better path.

btw- ietf-pcp-base is just yet another hack built onto NAT44 to try to
extend its life.  For the last 15 years the IPv4 sky was falling.  Now
it finally really is falling as the NAT hacks are coming undone in
many ways and the ISPs can't get addresses to build infrastructure.
The good news is now we can get something done with IPv6.

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

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <0edb3e2d-40f1-4bc8-9057-fe1d70f17...@ericsson.com>
Acee Lindem writes:
 
> On Oct 10, 2011, at 5:18 PM, Curtis Villamizar wrote:
>  
> >=20
> > In message 
> > Acee Lindem writes:
> >=20
> >=20
> > On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:
> >=20
> >>>=20
> >>> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
> >>>=20
>  Since OSPFv3 also uses a 4 byte router ID, our implementation will
>  use the same algorithm for picking a router ID as OSPFv2.
> >>>=20
> >>> which is to say "any old thing it wants, quite often an IPv4 =
> address"?
> >>=20
> >>=20
> >> Correct, it uses the best or only configured IPv4 address in the
> >> context (aka, virtual router). Of course, we'd want to use something
> >> else for true auto-configuration.
> >>=20
> >> Thanks,
> >> Acee=20
> >=20
> >=20
> > And on an IPv6 only homenet with no configured addresses it does what?
>  
> Our Ericsson SmartEdge routers were never meant to be deployed in the =
> home or to support complete auto-configuration - I was just responding =
> to Fred's query as to what OSPFv3 implementations do today.=20
> If there is no IPv4 address available and no OSPFv3 Router-ID is =
> explicitly configured, we'll log an error and shut the OSPFv3 instance =
> down until such time as an IPv4 address or explicit router-id are =
> configured.
> A new draft is required for OSPFv3 auto-configuration.=20
> Thanks,
> Acee
>  
> >=20
> > Curtis


Acee,

I'll have to confess that my most recent employer's equipement was
also not intended for the home.  :-)

I'm sure you saw the suggestions I made in another response.  The fix
for autoconfig may be to pick a random number and create an OSPF
extension to advertise the detection of a collision on a given
router-id, then respond to the collision.  Any device using autoconfig
would have to support this extension.  If colliding with a router that
did not support the extension, that other router would do nothing, but
the autoconfig router would pick a new router-id.

The point is you can't make a unique 32 bit number out of a 48 bit
number or a 64 bit number or an 80 bit number (for a /48).  So you
might as well accept low probability of collision and define a way to
fix the situation.

The absolute worst case is a stomped on LSA that an old router doesn't
update until maxage expires.  That would be bad so maybe we need to
figure out what a legacy OSPF router would do on such a collision
where it got from a neighbor something it did not send as its own LSA.
Hopefully it would readvertise the right stuff and try to withdraw the
bad stuff.  The autoconfig router would just pick a new router-id.

It all sounds fine except maybe the backwards compatibility with no
changes.  Your the OSPF expert so ...

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

Re: [homenet] Does ND Proxy useful for homenet?

[Rajeev Koodli]

Hi,

The smartphone will only get a /64 in the current 3G/4G releases (rel-8,
rel-9).

Prefix delegation is specified in Rel-10.

-Rajeev



On 10/10/11 1:01 PM, "Mark Townsley"  wrote:

>> 
>> Or are you saying a mobile device (a smartphone) will only ever get a
>> /64 to share?
> 
> My (limited) understanding of the various 3/4G standards are that a PD for a
> phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or
> someone else here can elucidate.
> 
> - Mark
> 

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

Re: [homenet] Homenet strawman slides

[Curtis Villamizar]

In message <2834.1318277...@marajade.sandelman.ca>
Michael Richardson writes:
 
>  
> > "Erik" == Erik Nordmark  writes:
> Erik> There might be some more difficult aspects if we want to allow
> Erik> a router or its interfaces to be repurposed, such as splitting
> Erik> an existing link into two separate links. In that case it
> Erik> might be hard to avoid renumbering. The requirements question
>  
> Moving/repurposing a router without a factory reset seems like the
> perhaps the most important source of conflict in the architecture that
> we discussed.  Particularly if the router is put into a junk drawer for
> a few months until it is needed.
>  
> So, we might need to consider if we can expire persisted settings after
> some long (from the point of view of the network) time, like 1 week...


If it is zero config and its persistent store is DHCP leases, then
they will expire.  OSPF advertisements would have aged out long ago.
It might be worth redoing the router-id selection if it is well past
the maxage limit and there are no adjacencies.

If the router is just power cycled when moving, it should ask for
certain IA-PD and may not get them (or make DHCPv4 requests for a
specific address).  The same link local requestors (or MAC on DHCPv4)
would not be on the new LANs and so the old granted leases that had
not expired would also do no harm.

What persistent storage, beside configuration by the user would last
more than a week?  AFAIK just having DHCP leases lasting more than a
week would also require some user configuration.

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

Re: [homenet] Does ND Proxy useful for homenet?

[Joel M. Halpern]

Curtis, I would not call what you describe "ground rules."  They are a 
valid and useful operating premise, used by many residential service 
providers.
Other service providers prefrer other architectures and state 
maintenance, in exchange for other capabilities.


While I would not want to insist that all edge home routers must be 
bridges, I find it unfortunate that folks seem to be insisting that they 
must be routers.


Yours,
Joel M. Halpern

On 10/10/2011 5:24 PM, Curtis Villamizar wrote:


In message
Mikael Abrahamsson writes:


On Sun, 9 Oct 2011, Shishio Tsuchiya wrote:


2^64 host address space would be too enough for homenet.


I would just like to comment on this even though you retracted your
question.

As an ISP, I do not want to participate in a home with hundreds or
thousands of active IPv6 addresses that I need to keep state for. Most
likely, when we have central equipment participating in a home network,
we'll implement a limit on number of neighbours it'll allow on the subnet.
Doing ND/NS a lot takes resources.

If customer wants to use more IPv6 addresses, we'll require them to get a
home router and PD address space to it to distribute the ND/NS load.

--
Mikael Abrahamssonemail: swm...@swm.pp.se



+1
violent agreement, etc

IMO the ground rules are: The ISP provides one prefix.  The homenet
subdivides it only if there are multiple subnets.  The ISP doesn't see
the longer prefixes that exist only within the homenet.

Curtis
___
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

Re: [homenet] Homenet strawman slides

[Curtis Villamizar]

In message <4e93358f.7050...@cisco.com>
Erik Nordmark writes:
 
> On 10/8/11 6:13 AM, Jari Arkko wrote:
> > I like this, with the possible exception of using ULAs and your desire
> > to deprecate prefixes as soon as connectivity goes down. (Speaking as
> > someone whose prefixes got invalidated two months ago but who hasn't
> > been home long enough to fix the problem, but my devices still happily
> > communicate with each other using the old prefixes :-) I also agree with
> > Erik that loop and arbitrary topologies is not really required. But the
> > people in the interim at least seemed to say yesterday that we want to
> > go there.
>  
> I think there are different scopes being discussed.
>  
> The one I put forth is how to enable existing IPv4 NATting consumer home 
> routers (which all have a designated uplink port, and support multiple 
> home routers by nested NATting) have a way to support IPv6 without 
> requiring any IPv6 NATs. That doesn't seem to be a difficult problem 
> (which perhaps makes it uninteresting for some of us), but to me it 
> seems like an important short-term problem to solve.
>  
> The larger scope is around arbitrary topologies, no designated uplink 
> port, and perhaps also multihoming. Plenty of problems to solve around 
> autoconfiguring routing protocols, stable prefix assignment to links, 
> multihoming, etc.


Erik,

I really don't know how many support calls are just the consumer
plugging the computer into the wrong Ethernet port on the NAT box and
the uplink on the other port and then not being able to figure out
what is wrong.  All the cables fit in the connector.  It should work!

If all the ports are the same, no designated uplink, that is better.
If you get an IP address via DHCP on one and none of the others, it
may be the uplink and try doing NAT.  What may be needed is a IPv4
equivalent to the IPv6 IA_PD and a provider DSL or docsis modem/router
that knows how to respond to it.  The other routers ask for a IA_PD
and the provider modem/router responds with part of 10/8 on each
interface (and does NAT).

The same loop tolerance can then be built into the IPv4 homenet using
16M addresses provided by NAT as can be provided for the IPv6 subnet
using a globally routable /64 (with its 4B^2 addresses).

The idea is that the consumer can plug things in in arbitrarily stupid
way and it will all still work well enough to not require a support
call.  It might work better if set up right, but good enough if set up
wrong.  Perhaps GbE can be preferred over 100baseT over 10baseT and
somewhere between 100baseT over 10baseT or after 10baseT fits WiFi.
Beyond that metrics for multiple WiFi hops can be channel aware.

> Some things are common across the two; security (determining the 
> boundary of the home), DNS, and service discovery.
>  
> Erik

The security boundary of WiFi for non-open WiFi is separate issue.
That can't easily be zero config.  Perhaps two devices can "bond" (in
the "fall in love" analogy sense) over an Ethernet or USB connection
as one way around the configuring WPA issue.

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

Re: [homenet] walled garden DNS

[Curtis Villamizar]

In message <8438.1318266...@marajade.sandelman.ca>
Michael Richardson writes:
 >  
> > "Erik" =3D=3D Erik Nordmark  writes:
> Erik> 4. Looking up foo.ispA.net works when asking the DNS server at
> Erik> ISP-A, but fails (NXDOMAIN) when asking ISP-B.
>  
> Erik> 5. The lookup of foo.ispA.net works over either DNS and
> Erik> returns the same IP address, but fails (due to firewalls) for
> Erik> packets that are sent out via ISP-B.
>  
> Erik> 6. The lookup of foo.ispA.net works over either DNS and
> Erik> returns the same IP address, but the application-layer content
> Erik> is completely different (e.g., a "subscriber" view when
> Erik> connecting over the ISP-A connection).
>  
> We have heard requests for a facility to provide hosts information of
> the sort:
> when looking for an FQDN that has suffix "X", please contact server "Y"
>  
> And my question is: isn't that what an NS record is?
>  
> It seems to me that we can solve all of the walled garden DNS in IPv6
> land, with an arrangement like:
>  
>   example.com   NS reachable by the world.
>   garden.example.comNS pointing to  record, where IPv6
> address is only reachable from garden.
>   television.garden.example.com returned from
> garden.example.com name server (above)
>  
> This solution works perfectly in IPv4 land, but due to lack of IPv4
> global address space, the NS for garden.example.com winds up pointing to
> RFC1918 address, and not only does this look bad, but it can in fact
> cause failures if there really is a DNS server at that address.
>  
> It seems to me that we just don't need anything else in IPv6, except
> easily *available* non-connected PI address space (whether it's ULA-C,
> some recognized part of 2000::/3, or an entirely new space).
>  
> NOTE: the existing ingress filtering problem means that one must assume
>   that walled gardens will have to provide address space to the home
>   that will be used to talk to them.  A challenge to the walled
>   garden people's thought process is that they might be thinking
>   that they need 1-IP per customer, when in fact, they need to have
>   at least a /60 per customer.


If this is a walled garden within the home, would it be simple enough
to use a 6to4 address space for one globally unique IPv4 address and
just not bring up a 6to4 tunnel?

Instant walled garden.  With private DNS.

Alternately bring up the 6to4 tunnel but don't propogate or forward on
the garden side.  If garden.example.com is the A record for the 6to4
and also has an  record, and it is also the DNS server within the
garden, then the DNS records are availabel both inside and outside but
connectivity is inside only.

Walled gardens always seem like a bad idea.  And probably always are a
bad idea.

If you have control over both the DHCP (4 or 6) server and the DNS
server, you can make DNS look like anything you want within the
garden.  [Except for those hosts who do their own DNS from root or have
configured a DNS forwarder from elsewhere.  Only the geeks.]

The original question seems to be whether the same dns query (for
example, garden.example.com) could be made to resolve differently in
ISP-A and ISP-B and the answer is "yes" with no changes but with the
exception within [] in the prior paragraph.

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

Re: [homenet] Homenet Architecture & Interim Meeting

[Curtis Villamizar]

In message <30133.1318261...@marajade.sandelman.ca>
Michael Richardson writes:
 
>  
> > "james" == james woodyatt  writes:
> >> There will be wide area network providers who interwork with the
> >> home network but do not provide global connectivity.  Two
> >> mentioned so far are utility networks and 3g providers.  One of
> >> the outputs of the wg should be to define how they should be
> >> configured to perform their role without messing up Internet
> >> communication.
>  
> james> Those utility networks have a fundamental problem that I
> james> contend is beyond the scope and charter of HOMENET.
>  
> james> Utility networks of that sort do not provide transit to the
> james> Internet default-free zone.  They must therefore obtain their
> james> routes to residential networks bilaterally.  This implies
> james> that these utility networks could be-- and would do well to
> james> be-- numbered with ULA prefixes, and that they should use of
>  
> If you said, "ULA-Central" I would agree.
> I do not want to debug random packets on someone's network without
> whois.
>  
> >> A wg Chair from the Internet area did accuse me of "breaking the
> >> Internet model" because the utility networks my company builds do
> >> not provide global connectivity to users with our 100kb to the
> >> node.
>  
> james> That's really not the problem, if you want my humble opinion.
> james> The problem, I would say, is that these utility networks
> james> insist on extending their private routing domains into our
> james> home networks where they don't belong and they aren't
> james> welcome.
>  
> It does break the *I*nternet model: the one where the ISPs control
> everything like the telcos did before, and I need to beg to be allowed
> to receive SYN packets.  Why do I care if it breaks the business plans
> of some ISPs?   
>  
> But the IETF needs to spend more time worrying about the *Internet
> Protocols* rather than just the *I*nternet.   

I completely agree with the WG chair on this one.

If the utility network wants to share a common homenet infrastructure
but remain disjoint from the Internet, then it must do so in a way
that doesn't break the other uses of the homenet.

One way may be to identify (somehow) those hosts that are using the
homenet for the purpose of connecting to the utility network, such as
the home heating system, the water header, etc and only offer
addressing and routing to that subset of equipment.

Another even simpler solution is to have the utility gateway stop
serving as an ND or DHCP server completely if it detects connectivity
to the Internet and just use that connectivity.  Surely the utility
can afford an Internet connection.  Use the Internet if it is there,
otherwise use the utility network.

OTOH - If the reason for avoiding the Internet is because an industry
came up with a meter protocol with no security assuming it was only
going to be used on a walled off private network, then that is not a
homenet WG issue either.

> >> [...]  6. The lookup of foo.ispA.net works over either DNS and
> >> returns the same IP address, but the application-layer content is
> >> completely different (e.g., a "subscriber" view when connecting
> >> over the ISP-A connection).
>  
> james> This is the basic problem faced by any multi-homed host,
> james> e.g. a personal computer with a 3G interface and a Wi-fi
> james> interface that are simultaneously active, along with a
> james> split-tunnel VPN interface [or three] running on one or both
> james> interfaces.
>  
> james> It is a problem for host operating systems and applications
> james> developers.  I suggest HOMENET should steer well clear of it,
> james> and just about every related problem that is too easily
> james> conflated with it.
>  
> What is the set of problems left for homenet then?

Certainly not solving the broken utility network issues.

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

Re: [homenet] Homenet Architecture & Interim Meeting

[james woodyatt]

On Oct 10, 2011, at 08:51 , Michael Richardson wrote:
> 
> It does break the *I*nternet model: the one where the ISPs control
> everything like the telcos did before, and I need to beg to be allowed
> to receive SYN packets.  Why do I care if it breaks the business plans
> of some ISPs?   

I hate to break the news to you, but it isn't the ISPs that are making you beg 
to receive a SYN packet from anywhere on the Internet.  It's the home gateway 
vendors, who are following the advice of RFC 4864 to implement stateful 
default-deny simple security mechanisms, and who follow the advice of myriad 
other 'experts' who insist that these functions be enabled by default.

Shorter james: it's your residential subscribers who insisting that your 
devices need to beg for permission to receive inbound SYN packets from 
arbitrary remote addresses.

The IETF is in the process of specifying a protocol to let you beg for incoming 
packets, c.f. I-D.ietf-pcp-base.  I wish you all the luck in the world 
convincing the average home networking gear buyer that they shouldn't need any 
of this craziness.  Sincerely.  I tried that.  Been there, done that, got the 
T-shirt, ended up buffing the car with it, donated the car to charity when the 
car wore out... in other words, I am done struggling against what you call "the 
Internet model" because from my perspective that's like to trying to bail out 
San Francisco bay with a tea cup.  Have fun storming the castle though...


--
james woodyatt 
member of technical staff, core os networking



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

Re: [homenet] Multilink subnet routing (MLSRv2)

[Ole Troan]

Erik,

>> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't 
>> really been described anywhere) as a method for numbering a routed home. 
>> please let me be clear that I'm not convinced this is a good idea. i.e. why 
>> not just get<  /64?
>> I do think we could get something working though.
>> 
>> routers can be in an arbitrary topology. all routers running a routing 
>> protocol.
>> the site prefix (/64) is either advertised in the IGP with a new LSA or 
>> proxying of RA messages is done (split horizon).
>> a router advertises the same /64 prefix (in a PIO) on all of its interfaces. 
>> L bit is 0.
>> 
>> the link model here is that all hosts are off link from each other. 
>> link-local scope is restricted to only the physical link. multicast 
>> link-local scope as well.
> 
> And I assume the routers would pass around /128 routes for the hosts in the 
> home, and would automatically inject such a route when the SAVI-style table 
> learns about a new address.
> Are those assumptions correct?

yes.

>> a host uses SLAAC (or DHCP) to create an address, then does DAD as normal. 
>> the first hop router uses it's routing topology database
>> to check for conflicts. similar mechanisms described in SAVI are used to 
>> glean address information from the host. the SAVI binding
>> database is then used to inject host routes into the IGP.
> 
> What happens when the router crashes - does it loose its SAVI-style table? 
> Does it keep it in stable storage?

it could.

> If it looses it, then nobody would know on what link the hosts are, since the 
> hosts aren't required to periodically send any announcement to the routers.

indeed. directly connected hosts would get a L2 event.
in the more creative department you could run with low timers, and you could 
enforce a direct mapping between MAC address, link-local address and global 
address.
thereby being able to recreate global address binding state just from a 
link-local addresses.

> What happens when a packet arrives for an IP address that is in the /64 
> prefix for the home, but there is no /128 route for it? Flood everywhere? 
> Drop?

drop I'd imagine.

> We looked that this when we worked on 6lowpan-nd, and concluded that by doing 
> explicit registrations from hosts to routers (the Address Registration 
> Option) with a lifetime we can make such networks work well without requiring 
> stable storage.
> 
> But that implies a host change.

yes, registration makes this safer.

I just intended to point out that this could be one tool in the toolbox. not 
that we should necessarily build homenets this way.

cheers,
Ole

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

Re: [homenet] Homenet Architecture & Interim Meeting

[Curtis Villamizar]

In message <4e92a0fc.5060...@globis.net>
Ray Hunter writes:
 
>  > The example of electric meters is a trivial one but the same can
>  > apply to other things.
>  
> I can assure you that the requirements and IT issues surrounding smart 
> electric meters are far from "trivial."
>  
> You talk about "the electric company" being singular and monolithic. In 
> reality there are many separate parties with interests in obtaining 
> access to that data and controlling that meter (the home owner, multiple 
> production/ delivery companies, meter data management company, meter 
> management company, high voltage distribution company, medium voltage 
> distribution company, regulators, micro generation  ) That can add 
> up to 15 different roles, and many different message types.
>  
> See e.g. /EBSII White Paper: "Smart European Energy Architecture"
>  
> or
>  
> http://www.google.nl/url?sa=t&source=web&cd=4&ved=0CC0QFjAD&url=http%3A%2F%2Fwww.esmig.eu%2Fnewsstor%2Fnews-file-store%2FEU-MeteringV4.pdf%2Fat_download%2Ffile&rct=j&q=EBSII%20White%20Paper%3A%20%E2%80%9CSmart%20European%20Energy%20Architecture%E2%80%9D&ei=JZ-STvnTLMmg-wbm6qHTCg&usg=AFQjCNGpFWhNfa1HeBA24wlVPwLEFB0T6A&sig2=CT0FCDXVmniyxMoSup9SPw&cad=rja
>  
>  
> regards,
> RayH


OK - modify that statement to: The example *as stated* of electric
meters is a trivial one but the same can apply to other things.
*However never underestimate an industry's ability to make a simple
problem highly complex*.  :-)

Either way the mess the electrical industry is making for itself is
out of scope here.

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

Re: [homenet] Thoughts about routing

[Acee Lindem]

On Oct 10, 2011, at 5:18 PM, Curtis Villamizar wrote:

> 
> In message 
> Acee Lindem writes:
> 
> 
> On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:
> 
>>> 
>>> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
>>> 
 Since OSPFv3 also uses a 4 byte router ID, our implementation will
 use the same algorithm for picking a router ID as OSPFv2.
>>> 
>>> which is to say "any old thing it wants, quite often an IPv4 address"?
>> 
>> 
>> Correct, it uses the best or only configured IPv4 address in the
>> context (aka, virtual router). Of course, we'd want to use something
>> else for true auto-configuration.
>> 
>> Thanks,
>> Acee 
> 
> 
> And on an IPv6 only homenet with no configured addresses it does what?

Our Ericsson SmartEdge routers were never meant to be deployed in the home or 
to support complete auto-configuration - I was just responding to Fred's query 
as to what OSPFv3 implementations do today. 
If there is no IPv4 address available and no OSPFv3 Router-ID is explicitly 
configured, we'll log an error and shut the OSPFv3 instance down until such 
time as an IPv4 address or explicit router-id are configured.
A new draft is required for OSPFv3 auto-configuration. 
Thanks,
Acee

> 
> Curtis
> ___
> 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

Re: [homenet] Multilink subnet routing (MLSRv2)

[Curtis Villamizar]

In message 
"Pascal Thubert (pthubert)" writes:
 
> Hi Ole:
>  
> I think you're getting closer and closer to the models that were
> discussed in RPL, 6LoWPAN and Autoconf.
>  
> There are several components to the solution that was proposed there:
> - capability to register an IPv6 address using ND extensions
> - capability to extend a subnet over multiple hops (RPL DIO prefix
> option) 
> - capability to redistribute ND registration into  the MLSN routing
> protocol
> - capability to use the ND registrar (and/or) the routing protocol for
> DAD
> - capability for the registrar to proxy ND over a backbone in order to
> interact with classical ND clients
>  
> See:
> http://tools.ietf.org/html/rfc5889 
> http://tools.ietf.org/html/draft-ietf-6lowpan-nd 
> http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router
>  
> cheers,
>  
> Pascal


IMHO - Any attempts to use ND Proxy masquerading as a light weight
routing protocol are doomed.  Failing to deal with the problems of
loops in the topology and multiple attachments to the provider will
just push the problem from protocol definition to customer support
(when the customer's network doesn't work).

It is better to get it 100% right in protocol definition, than 90%
right with the other 10% going to support calls.

Curtis


> -Original Message-
> From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On
> Behalf Of Ole Troan
> Sent: lundi 10 octobre 2011 00:38
> To: Erik Nordmark (nordmark)
> Cc: homenet@ietf.org
> Subject: [homenet] Multilink subnet routing (MLSRv2)
>  
> Erik, et al,
>  
> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it
> hasn't really been described anywhere) as a method for numbering a
> routed home. please let me be clear that I'm not convinced this is a
> good idea. i.e. why not just get < /64?
> I do think we could get something working though.
>  
> routers can be in an arbitrary topology. all routers running a routing
> protocol.
> the site prefix (/64) is either advertised in the IGP with a new LSA or
> proxying of RA messages is done (split horizon).
> a router advertises the same /64 prefix (in a PIO) on all of its
> interfaces. L bit is 0.
>  
> the link model here is that all hosts are off link from each other.
> link-local scope is restricted to only the physical link. multicast
> link-local scope as well.
>  
> a host uses SLAAC (or DHCP) to create an address, then does DAD as
> normal. the first hop router uses it's routing topology database to
> check for conflicts. similar mechanisms described in SAVI are used to
> glean address information from the host. the SAVI binding database is
> then used to inject host routes into the IGP.
>  
> this requires no flooding of ND, or any other changes to on-link
> protocols for loop detection. no changes in hosts either.
> only downside is that it requires a host to have sent a packet of some
> form for the SAVI binding to be initiated.
> it might also be possible to support host mobility with the home with
> this mechanism.
>  
> cheers,
> Ole
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Curtis Villamizar]

In message 
Mikael Abrahamsson writes:
 
> On Sun, 9 Oct 2011, Shishio Tsuchiya wrote:
>  
> > 2^64 host address space would be too enough for homenet.
>  
> I would just like to comment on this even though you retracted your 
> question.
>  
> As an ISP, I do not want to participate in a home with hundreds or 
> thousands of active IPv6 addresses that I need to keep state for. Most 
> likely, when we have central equipment participating in a home network, 
> we'll implement a limit on number of neighbours it'll allow on the subnet. 
> Doing ND/NS a lot takes resources.
>  
> If customer wants to use more IPv6 addresses, we'll require them to get a 
> home router and PD address space to it to distribute the ND/NS load.
>  
> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se


+1
violent agreement, etc

IMO the ground rules are: The ISP provides one prefix.  The homenet
subdivides it only if there are multiple subnets.  The ISP doesn't see
the longer prefixes that exist only within the homenet.

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

Re: [homenet] Multilink subnet routing (MLSRv2)

[Curtis Villamizar]

In message <17d930d0-572c-482e-8be7-e782e4930...@townsley.net>
Mark Townsley writes:
 
>  
> it would seem that we only have 3 choices once we run out of /64s to
> give out on links that for whatever reason we cannot bridge on.
>  
> 1. No IPv6
> 2. NAT IPv6 
> 3. MLSRv2 (if what you propose works, I don't yet see why it wouldn't)
>  
> I think this is a case of what is the least bad option. We shouldn't
> ignore the problem though.
>  
> - Mark


There is no reason to give out /64 or shorter to every link.

A prefix longer than /64 is not *globally* routeable.  It is locally
routeable.


> On Oct 9, 2011, at 6:38 PM, Ole Troan wrote:
>  
> > Erik, et al,
> > 
> > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't 
> > really been described anywhere) as a method for numbering a routed home. 
> > please let me be clear that I'm not convinced this is a good idea. i.e. why 
> > not just get < /64?
> > I do think we could get something working though.
> > 
> > routers can be in an arbitrary topology. all routers running a routing 
> > protocol.
> > the site prefix (/64) is either advertised in the IGP with a new LSA or 
> > proxying of RA messages is done (split horizon).
> > a router advertises the same /64 prefix (in a PIO) on all of its 
> > interfaces. L bit is 0.
> > 
> > the link model here is that all hosts are off link from each other. 
> > link-local scope is restricted to only the physical link. multicast 
> > link-local scope as well.
> > 
> > a host uses SLAAC (or DHCP) to create an address, then does DAD as normal. 
> > the first hop router uses it's routing topology database
> > to check for conflicts. similar mechanisms described in SAVI are used to 
> > glean address information from the host. the SAVI binding
> > database is then used to inject host routes into the IGP.
> > 
> > this requires no flooding of ND, or any other changes to on-link protocols 
> > for loop detection. no changes in hosts either.
> > only downside is that it requires a host to have sent a packet of some form 
> > for the SAVI binding to be initiated.
> > it might also be possible to support host mobility with the home with this 
> > mechanism.
> > 
> > cheers,
> > Ole
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message 
Acee Lindem writes:


On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:
 
> > 
> > On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
> > 
> >> Since OSPFv3 also uses a 4 byte router ID, our implementation will
> >> use the same algorithm for picking a router ID as OSPFv2.
> > 
> > which is to say "any old thing it wants, quite often an IPv4 address"?
>  
>  
> Correct, it uses the best or only configured IPv4 address in the
> context (aka, virtual router). Of course, we'd want to use something
> else for true auto-configuration.
>  
> Thanks,
> Acee 


And on an IPv6 only homenet with no configured addresses it does what?

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

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <635c3a25-7265-402d-a708-3a07b08ef...@cisco.com>
Fred Baker writes:
 
> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
>  
> > Since OSPFv3 also uses a 4 byte router ID, our implementation will
> > use the same algorithm for picking a router ID as OSPFv2.
>  
> which is to say "any old thing it wants, quite often an IPv4 address"?


A practical solution (of days past) using OSPF was to configure an
address that was not a link address, and then configure it as an alias
to the loopback and also advertise it as a /32 stub, and then tweak
applications to bind to that address.  This loopback address was
reachable even if an Ethernet subnet was partitioned (common).

Providers have all done this on their IPv4-only routers, allocating
the router-id from one or more small prefix which within the network
was all host routes.  That was fine for small number of routers
(hundreds or thousands) and lots of global prefixes (hundreds of
thousand) [note: "or" in the first case; "of" in the second case].

In the absense of this configuration or in an IPv6 network, the
assumption that the router-id is a reachable address is not a good
one.  It is also discouraged by the standards.

An IPv6 /64 has 2 sets of 4 bytes in every address even after tossing
out the top 64 bits.  So picking an address won't work.

What is really needed is a means to recover from a router-id
collision.  One router can detect another using the same router-id
easily enough.  An extension is needed to indicate a collision (there
is a denial of service potential with this).  The behaviour could be
for each router using that router-id (and supporting the extension) to
make another pick and readvertise.  It means taking down adjacencies
and bringing them back up, but perhaps a graceful restart extension
could smooth this.

This is putting lots of code in the little homenet router,
particularly if graceful restart is used.

Random number selection for router-id and this sort of recovery would
solve the zero config OSPF issue related to router-id selection.

Not yet solved in existing zospf draft (afaik) but solvable.

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

Re: [homenet] Multilink subnet routing (MLSRv2)

[Curtis Villamizar]

In message 
Ole Troan writes:
 
> Erik, et al,
>  
> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it
> hasn't really been described anywhere) as a method for numbering a
> routed home. please let me be clear that I'm not convinced this is a
> good idea. i.e. why not just get < /64?  I do think we could get
> something working though.

Having missed the meeting, anything more recent on MLSR than this:

  draft-ietf-ipv6-multilink-subnets-00
  Multi-link Subnet Support in IPv6 (2002-07-08, Expired)

  draft-thaler-ipngwg-multilink-subnets-02
  Multi-link Subnet Support in IPv6 (2001-11-29, Expired)

The only reference to MLSR in an RFC is in an IAB RFC, RFC4903:

   There was also a proposal to define multi-link subnets [MLSR] for
   IPv6.  However, this notion was abandoned by the IPv6 WG due to the
   issues discussed in this memo, and that proposal was replaced by a
   different mechanism that preserves the notion that a subnet spans
   only one link [RFC4389].

As to the second comment regarding /64: The magic /64 boundary should
be interpreted as follows:

  Anything shorter than or equal to /64 can be globally routable.

  Anything longer than /64 may not be globally routable.

For core routers the usual behaviour (or at least goal) is:

  Anything shorter than or equal to /64 can be forwarded at full
  speed, even for long bursts of very small packets.

  For anything matching a 64 bit "local subnet" address, look at the
  bottom /64 and still forward at full speed, even for long bursts of
  very small packets.

  For everything else (ie: not in a local subnet, and longer than /64
  prefix) forward anyway, but maybe not at full speed.

The whole purpose of this is that longer LPM lookups take time and at
high speed like like 10 Gb/s or 100 Gb/s (or more), it is really hard
to go faster without a high cost in silicon die area and power (and
worse yet for anything using external TCAM, two external lookups).

The /64 boundary was rather arbitrary.  (And IMNSHO further evidence
that 128 bit addrseeses was a bone headed choice and much too long,
but it is way too late by about a decade or more to change that).

There is no reasons that homenets (generally supporting 1 Gb/s or
less) can't further subnet a /64.

> routers can be in an arbitrary topology. all routers running a routing
> protocol.  the site prefix (/64) is either advertised in the IGP with
> a new LSA or proxying of RA messages is done (split horizon).  a
> router advertises the same /64 prefix (in a PIO) on all of its
> interfaces. L bit is 0.
>  
> the link model here is that all hosts are off link from each
> other. link-local scope is restricted to only the physical
> link. multicast link-local scope as well.

Not a good assumption.  There will still be dumb Ethernet switches and
bridging only WiFi hubs out there for a long time, so multiple hosts
on a subnet/link.

> a host uses SLAAC (or DHCP) to create an address, then does DAD as
> normal. the first hop router uses it's routing topology database to
> check for conflicts. similar mechanisms described in SAVI are used to
> glean address information from the host. the SAVI binding database is
> then used to inject host routes into the IGP.

Neither SLAAC (rfc2462) or DHCP6 (rfc3315) supports allocation of a
non-link-local prefix for the purpose of subdividing a prefix.  For
example, in DHCP6, the IA_TA and IA_NA are assumed to be link-local.
The IA-PD added this capability to DHCP6, but there is no
corresponding addition to SLAAC, so DHCP6 is preferred for routers.

Where multiple routers exist, all will initially be sending an IA-PD
request to each other.  If there is no connectivity to a service
provider who responds to an IA-PD, and none of the routers are
configured, then none should respond (can't sub allocate what you
don't have).

If the provider sends an IA-PD, response with a /64, then that border
router can respond with suballocations.  There is no guidance in
rfc3633 as to what to initially send in a IA-PD, but I suggest the
following (which lacks loop suppression):

  send 0/112 (65K addressses) initially

  send 0/[len+8] if the following are both true:
the router has received an IA-PD request from another router, and
the router already has a prefix assignment, and
the existing prefix assignment is too small, and
len is the longest prefix length it has

What is needed then is request loop suppression.  A new IA-PD would be
needed.  One possibility is a new IA-PD option in which the set of
IA-PD requestors is listed.  This creates a path vector loop
suppression, much like BGP using AS numbers.  If a router gets two
replies, prefer the one with the shorter path.

Having set up one or more prefixes, a router can then select a
router-Id (non-trivial) and start running a link state IGP (or link
state IGP with specialized metric for LLN or whatever).  That will
have to be the topic of another thread (please).

Another issue brought up is a multih

Re: [homenet] Homenet strawman slides

[Michael Richardson]

> "Erik" == Erik Nordmark  writes:
Erik> There might be some more difficult aspects if we want to allow
Erik> a router or its interfaces to be repurposed, such as splitting
Erik> an existing link into two separate links. In that case it
Erik> might be hard to avoid renumbering. The requirements question

Moving/repurposing a router without a factory reset seems like the
perhaps the most important source of conflict in the architecture that
we discussed.  Particularly if the router is put into a junk drawer for
a few months until it is needed.

So, we might need to consider if we can expire persisted settings after
some long (from the point of view of the network) time, like 1 week...

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Mark Townsley]

On Oct 10, 2011, at 3:59 PM, Cameron Byrne wrote:

> On Mon, Oct 10, 2011 at 12:41 PM, Michael Richardson  
> wrote:
>> 
>>> "Mikael" == Mikael Abrahamsson  writes:
>>>> Agreed. But I think it is worth noting that nd-proxy is practical
>>>> in mobile networks where each subscriber gets a unique /64.
>>>>
>>>> Mobile network attachment has popped up a few times in homenet
>>>> discussions.
>> 
>>Mikael> I think ND proxy has some use even in other cases, I would
>>Mikael> just like to be sure that there is consensus that this won't
>>Mikael> scale to a home with lots and lots of devices. The number 10
>>Mikael> or 16 simulatenous active IPv6 addresses comes to mind,
>>Mikael> after that I don't want to know what they have in their home
>>Mikael> anymore, they'll have to route it themselves.
>> 
>> So, I think that most of us were thinking that proxy-ND is what the home
>> does when the home runs out of it's /60.  I don't see why the ISP would
>> ever see this.
>> 
>> Or are you saying a mobile device (a smartphone) will only ever get a
>> /64 to share?
>> 
> 
> Today, yes.  GSM/UMTS/LTE devices today only support local /64 from
> the mobile network, AFAIK... and I have seen implementations of ND
> Proxy.  I have not seen anything aside from providing one network
> provided IPv4 address per mobile device (then the mobile will do its
> own NAT44 of that address)... but i may just be missing something
> there.  My infrastructure is only setup to provide 1 IPv4 address
> and/or 1 /64 of IPv6.
> 
> Some future spec's from 3GPP will allow for DHCPv6-PD, but that is
> forthcoming standards work and implementations.

Cameron not only beat me with an answer, he provided a more informed one. 
Thanks!

- Mark

> 
> Cameron
> 
> 
>> --
>> ]   He who is tired of Weird Al is tired of life!   |  firewalls 
>>  [
>> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net 
>> architect[
>> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
>> driver[
>>   Kyoto Plus: watch the video 
>>   then sign the petition.
>> 
>> 
>> ___
>> 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

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

Re: [homenet] Does ND Proxy useful for homenet?

[Mark Townsley]

On Oct 10, 2011, at 3:41 PM, Michael Richardson wrote:

> 
>> "Mikael" == Mikael Abrahamsson  writes:
>>> Agreed. But I think it is worth noting that nd-proxy is practical
>>> in mobile networks where each subscriber gets a unique /64.
>>> 
>>> Mobile network attachment has popped up a few times in homenet
>>> discussions.
> 
>Mikael> I think ND proxy has some use even in other cases, I would
>Mikael> just like to be sure that there is consensus that this won't
>Mikael> scale to a home with lots and lots of devices. The number 10
>Mikael> or 16 simulatenous active IPv6 addresses comes to mind,
>Mikael> after that I don't want to know what they have in their home
>Mikael> anymore, they'll have to route it themselves.
> 
> So, I think that most of us were thinking that proxy-ND is what the home
> does when the home runs out of it's /60.  I don't see why the ISP would
> ever see this.   
> 
> Or are you saying a mobile device (a smartphone) will only ever get a
> /64 to share?

My (limited) understanding of the various 3/4G standards are that a PD for a 
phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or someone 
else here can elucidate. 

- Mark

> 
> -- 
> ]   He who is tired of Weird Al is tired of life!   |  firewalls  
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net 
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
> driver[
>   Kyoto Plus: watch the video 
>  then sign the petition. 
> 
> ___
> 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

Re: [homenet] Does ND Proxy useful for homenet?

[Cameron Byrne]

On Mon, Oct 10, 2011 at 12:41 PM, Michael Richardson  wrote:
>
>> "Mikael" == Mikael Abrahamsson  writes:
>    >> Agreed. But I think it is worth noting that nd-proxy is practical
>    >> in mobile networks where each subscriber gets a unique /64.
>    >>
>    >> Mobile network attachment has popped up a few times in homenet
>    >> discussions.
>
>    Mikael> I think ND proxy has some use even in other cases, I would
>    Mikael> just like to be sure that there is consensus that this won't
>    Mikael> scale to a home with lots and lots of devices. The number 10
>    Mikael> or 16 simulatenous active IPv6 addresses comes to mind,
>    Mikael> after that I don't want to know what they have in their home
>    Mikael> anymore, they'll have to route it themselves.
>
> So, I think that most of us were thinking that proxy-ND is what the home
> does when the home runs out of it's /60.  I don't see why the ISP would
> ever see this.
>
> Or are you saying a mobile device (a smartphone) will only ever get a
> /64 to share?
>

Today, yes.  GSM/UMTS/LTE devices today only support local /64 from
the mobile network, AFAIK... and I have seen implementations of ND
Proxy.  I have not seen anything aside from providing one network
provided IPv4 address per mobile device (then the mobile will do its
own NAT44 of that address)... but i may just be missing something
there.  My infrastructure is only setup to provide 1 IPv4 address
and/or 1 /64 of IPv6.

Some future spec's from 3GPP will allow for DHCPv6-PD, but that is
forthcoming standards work and implementations.

Cameron


> --
> ]       He who is tired of Weird Al is tired of life!           |  firewalls  
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net 
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
> driver[
>   Kyoto Plus: watch the video 
>                       then sign the petition.
>
>
> ___
> 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

Re: [homenet] Does ND Proxy useful for homenet?

[Michael Richardson]

> "Mikael" == Mikael Abrahamsson  writes:
>> Agreed. But I think it is worth noting that nd-proxy is practical
>> in mobile networks where each subscriber gets a unique /64.
>> 
>> Mobile network attachment has popped up a few times in homenet
>> discussions.

Mikael> I think ND proxy has some use even in other cases, I would
Mikael> just like to be sure that there is consensus that this won't
Mikael> scale to a home with lots and lots of devices. The number 10
Mikael> or 16 simulatenous active IPv6 addresses comes to mind,
Mikael> after that I don't want to know what they have in their home
Mikael> anymore, they'll have to route it themselves.

So, I think that most of us were thinking that proxy-ND is what the home
does when the home runs out of it's /60.  I don't see why the ISP would
ever see this.   

Or are you saying a mobile device (a smartphone) will only ever get a
/64 to share?

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 



pgp9dcyMSoKpl.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Multilink subnet routing (MLSRv2)

[Mark Townsley]

On Oct 10, 2011, at 2:43 PM, Erik Nordmark wrote:

> On 10/9/11 3:38 PM, Ole Troan wrote:
>> Erik, et al,
>> 
>> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't 
>> really been described anywhere) as a method for numbering a routed home. 
>> please let me be clear that I'm not convinced this is a good idea. i.e. why 
>> not just get<  /64?
>> I do think we could get something working though.
>> 
>> routers can be in an arbitrary topology. all routers running a routing 
>> protocol.
>> the site prefix (/64) is either advertised in the IGP with a new LSA or 
>> proxying of RA messages is done (split horizon).
>> a router advertises the same /64 prefix (in a PIO) on all of its interfaces. 
>> L bit is 0.
>> 
>> the link model here is that all hosts are off link from each other. 
>> link-local scope is restricted to only the physical link. multicast 
>> link-local scope as well.
> 
> And I assume the routers would pass around /128 routes for the hosts in the 
> home, and would automatically inject such a route when the SAVI-style table 
> learns about a new address.
> Are those assumptions correct?
> 
>> a host uses SLAAC (or DHCP) to create an address, then does DAD as normal. 
>> the first hop router uses it's routing topology database
>> to check for conflicts. similar mechanisms described in SAVI are used to 
>> glean address information from the host. the SAVI binding
>> database is then used to inject host routes into the IGP.
> 
> What happens when the router crashes - does it loose its SAVI-style table? 
> Does it keep it in stable storage?
> 
> If it looses it, then nobody would know on what link the hosts are, since the 
> hosts aren't required to periodically send any announcement to the routers.
> 
> What happens when a packet arrives for an IP address that is in the /64 
> prefix for the home, but there is no /128 route for it? Flood everywhere? 
> Drop?
> 
> We looked that this when we worked on 6lowpan-nd, and concluded that by doing 
> explicit registrations from hosts to routers (the Address Registration 
> Option) with a lifetime we can make such networks work well without requiring 
> stable storage.

I heard a lot about stable storage being a requirement for a homenet router... 
and not much objection from the vendor reps. Perhaps that is a difference 
between homenet and lowpan.

- Mark

> 
> But that implies a host change.
> 
>   Erik
> 
>> this requires no flooding of ND, or any other changes to on-link protocols 
>> for loop detection. no changes in hosts either.
>> only downside is that it requires a host to have sent a packet of some form 
>> for the SAVI binding to be initiated.
>> it might also be possible to support host mobility with the home with this 
>> mechanism.
>> 
>> cheers,
>> Ole
>> 
> 
> ___
> 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

Re: [homenet] Multilink subnet routing (MLSRv2)

[Erik Nordmark]

On 10/9/11 3:38 PM, Ole Troan wrote:

Erik, et al,

to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't really 
been described anywhere) as a method for numbering a routed home. please let me be 
clear that I'm not convinced this is a good idea. i.e. why not just get<  /64?
I do think we could get something working though.

routers can be in an arbitrary topology. all routers running a routing protocol.
the site prefix (/64) is either advertised in the IGP with a new LSA or 
proxying of RA messages is done (split horizon).
a router advertises the same /64 prefix (in a PIO) on all of its interfaces. L 
bit is 0.

the link model here is that all hosts are off link from each other. link-local 
scope is restricted to only the physical link. multicast link-local scope as 
well.


And I assume the routers would pass around /128 routes for the hosts in 
the home, and would automatically inject such a route when the 
SAVI-style table learns about a new address.

Are those assumptions correct?


a host uses SLAAC (or DHCP) to create an address, then does DAD as normal. the 
first hop router uses it's routing topology database
to check for conflicts. similar mechanisms described in SAVI are used to glean 
address information from the host. the SAVI binding
database is then used to inject host routes into the IGP.


What happens when the router crashes - does it loose its SAVI-style 
table? Does it keep it in stable storage?


If it looses it, then nobody would know on what link the hosts are, 
since the hosts aren't required to periodically send any announcement to 
the routers.


What happens when a packet arrives for an IP address that is in the /64 
prefix for the home, but there is no /128 route for it? Flood 
everywhere? Drop?


We looked that this when we worked on 6lowpan-nd, and concluded that by 
doing explicit registrations from hosts to routers (the Address 
Registration Option) with a lifetime we can make such networks work well 
without requiring stable storage.


But that implies a host change.

   Erik


this requires no flooding of ND, or any other changes to on-link protocols for 
loop detection. no changes in hosts either.
only downside is that it requires a host to have sent a packet of some form for 
the SAVI binding to be initiated.
it might also be possible to support host mobility with the home with this 
mechanism.

cheers,
Ole



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

Re: [homenet] Thoughts about routing

[Erik Nordmark]

On 10/9/11 8:33 AM, Michael Richardson wrote:



"Erik" == Erik Nordmark  writes:

 Erik>  Reason I'm asking is that I have two consumer devices with
 Erik>  IPv4 NAT in my home (a VoIP box and a backup device) where the
 Erik>  instructions said: 1. Insert between or existing router (or PC
 Erik>  if you have no router) and the DSL/cable modem 2. Insert
 Erik>  between your PC and your existing router (or modem if you have
 Erik>  no router)

 Erik>  Those consumer instructions naturally result in a daisy-chain
 Erik>  of IPv4 RGs/NATs, which is a subset of a tree topology.

That's a good point:  many VoIP ATAs want to be the first device so that
they can control the QoS, and ideally get the public IP address.

Does your VoIP box do PPPoE as well?


Yes.

It is basically a home gateway (without WiFi - wired Ethernet only) with 
a SIM slot and a phone connector added. Thus it has all the usual 
protocols and knobs for Internet connectivity.


The backup device takes the same approach - start with a home gateway 
and add something (in that case a disk plus file sharing software) but 
don't remove anything.


  Erik

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

Re: [homenet] Homenet strawman slides

[Erik Nordmark]

On 10/8/11 6:14 AM, Jari Arkko wrote:


I think we first need to agree on what we think are the requirements
on prefix stability. What if one of the routers attached to the link
fails and is replaced by a different router?
What if a link partitions? And later merges?
What the user intentionally splits (partitions) a link (e.g., to
create a separate link for the teenage game room); should the network
automatically pick a new prefix for that new link? (How does that
interact with the prefix being in stable storage on the router.)


We talked about the stability requirements on Thursday a bit. From my
perspective the requirement is that crashes, power outages/recycles, and
addition of new devices must not cause existing allocations to change.
Other changes they may, and I think it would be too much effort and
complexity to try to prevent all changes in all situations.


I suspect that if we can solve the above cases (e.g., for a link with 
two routers that crash, get powered off and on, and then later the user 
adds a third router to connect up with the garage network), then we will 
end up with something rather complete.


There might be some more difficult aspects if we want to allow a router 
or its interfaces to be repurposed, such as splitting an existing link 
into two separate links. In that case it might be hard to avoid 
renumbering. The requirements question is whether the system needs to be 
able to detect that the link is now (intentionally) partitioned and as a 
result there are two separate prefixes needed for the two separate 
links, or whether the user needs to be able to push the "reset to 
factory defaults" if the user is going to reconfigure the topology in 
such ways.


   Erik

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

Re: [homenet] Homenet strawman slides

[Erik Nordmark]

On 10/8/11 6:13 AM, Jari Arkko wrote:

I like this, with the possible exception of using ULAs and your desire
to deprecate prefixes as soon as connectivity goes down. (Speaking as
someone whose prefixes got invalidated two months ago but who hasn't
been home long enough to fix the problem, but my devices still happily
communicate with each other using the old prefixes :-) I also agree with
Erik that loop and arbitrary topologies is not really required. But the
people in the interim at least seemed to say yesterday that we want to
go there.


I think there are different scopes being discussed.

The one I put forth is how to enable existing IPv4 NATting consumer home 
routers (which all have a designated uplink port, and support multiple 
home routers by nested NATting) have a way to support IPv6 without 
requiring any IPv6 NATs. That doesn't seem to be a difficult problem 
(which perhaps makes it uninteresting for some of us), but to me it 
seems like an important short-term problem to solve.


The larger scope is around arbitrary topologies, no designated uplink 
port, and perhaps also multihoming. Plenty of problems to solve around 
autoconfiguring routing protocols, stable prefix assignment to links, 
multihoming, etc.


Some things are common across the two; security (determining the 
boundary of the home), DNS, and service discovery.


   Erik

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

Re: [homenet] Multilink subnet routing (MLSRv2)

[Michael Richardson]

> "Ole" == Ole Troan  writes:
Ole> we (as in homenet) do not want to require host changes.  I also
Ole> think the issues with flooding ND has been explored in RFC4903.

RPL benefits from host changes, but if you provide proxy-ND for the
hosts which have not changed, then it much the same as MLSRv2, I think.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Mikael Abrahamsson]

On Mon, 10 Oct 2011, Cameron Byrne wrote:

Agreed. But I think it is worth noting that nd-proxy is practical in 
mobile networks where each subscriber gets a unique /64.


Mobile network attachment has popped up a few times in homenet 
discussions.


I think ND proxy has some use even in other cases, I would just like to be 
sure that there is consensus that this won't scale to a home with lots and 
lots of devices. The number 10 or 16 simulatenous active IPv6 addresses 
comes to mind, after that I don't want to know what they have in their 
home anymore, they'll have to route it themselves.


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

Thanks. That is a big update to my numbers, but one that is important here.

On Oct 10, 2011, at 10:18 AM, STARK, BARBARA H wrote:

> The subset of tree topology where a consumer places ones router behind
> another router is *extremely* common. Statistics I saw several years ago
> suggested that probably about 60% of ADSL customers in the US use this
> topology. The most common cause for this topology is where the service
> provider supplies a free ADSL router with a single port to a subscriber,
> and the subscriber then puts their own multi-port router behind that
> router. The ADSL router is configured to do the PPPoE, and is also
> configured to automatically provide whatever public IP address it gets
> to whatever is behind it (via DHCPv4, as a sort of automatic DMZ
> function -- the ADSL router also uses that public IP address for its
> needs). The ADSL router is often set to provide only that one address,
> and not to support a full network of devices. Which is why consumers are
> forced to use their own router. This also tends to be how VoIP router +
> consumer's wireless router topology works.
> 
> I'm sure some people would like to argue as to why this is bad, or it
> shouldn't be done. I'm not going to get into that argument. That
> argument is irrelevant. The fact is that it's very, very common. 
> 
> I agree with those who say that we *don't* need to make sure IPv4 works
> everywhere that IPv6 works.
> But I think it's an absolute requirement that IPv6 MUST work everywhere
> that IPv4 works.
> 
> And this is a very common case where IPv4 works. When going to IPv6, the
> ADSL router will also be the device that establishes the IPv6
> connection. Because the credentials are the same as for IPv4, and the
> secondary router doesn't have those credentials. And the consumer forgot
> the credentials long ago, and doesn't remember how to configure this
> stuff anyway.
> 
> IMO, I believe that the best approach would be to solve tree
> generically. Which means that the probability of "tree network" would
> actually be "common, perhaps 30th percentile" (dividing my "60% in ADSL
> networks" by 2).
> Barbara
> 
>> -Original Message-
>> On 10/7/11 12:48 AM, Fred Baker wrote:
>>> I suggested that the probability of use of each of the scenarios on
>> slide 4 were
>>>  single router network: 90th percentile
>>>  tree network:  unusual
>>>  multi-router:  perhaps 5th percentile
>>>  multihomed:unusual
>> 
>> Fred,
>> 
>> are the above numbers based on any survey data?
>> 
>> Reason I'm asking is that I have two consumer devices with IPv4 NAT in
>> my home (a VoIP box and a backup device) where the instructions said:
>> 1. Insert between or existing router (or PC if you have no router) and
>> the DSL/cable modem
>> 2. Insert between your PC and your existing router (or modem if you
>> have
>> no router)
>> 
>> Those consumer instructions naturally result in a daisy-chain of IPv4
>> RGs/NATs, which is a subset of a tree topology.
>> 
>> I can't be the only person who have a VoIP box or a Time Capsule.
>> 
>>Erik
>> ___
>> 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

[homenet] walled garden DNS

[Michael Richardson]

> "Erik" == Erik Nordmark  writes:
Erik> 4. Looking up foo.ispA.net works when asking the DNS server at
Erik> ISP-A, but fails (NXDOMAIN) when asking ISP-B.

Erik> 5. The lookup of foo.ispA.net works over either DNS and
Erik> returns the same IP address, but fails (due to firewalls) for
Erik> packets that are sent out via ISP-B.

Erik> 6. The lookup of foo.ispA.net works over either DNS and
Erik> returns the same IP address, but the application-layer content
Erik> is completely different (e.g., a "subscriber" view when
Erik> connecting over the ISP-A connection).

We have heard requests for a facility to provide hosts information of
the sort:
when looking for an FQDN that has suffix "X", please contact server "Y"

And my question is: isn't that what an NS record is?

It seems to me that we can solve all of the walled garden DNS in IPv6
land, with an arrangement like:

  example.com   NS reachable by the world.
  garden.example.comNS pointing to  record, where IPv6
address is only reachable from garden.
  television.garden.example.com returned from
garden.example.com name server (above)

This solution works perfectly in IPv4 land, but due to lack of IPv4
global address space, the NS for garden.example.com winds up pointing to
RFC1918 address, and not only does this look bad, but it can in fact
cause failures if there really is a DNS server at that address.

It seems to me that we just don't need anything else in IPv6, except
easily *available* non-connected PI address space (whether it's ULA-C,
some recognized part of 2000::/3, or an entirely new space).

NOTE: the existing ingress filtering problem means that one must assume
  that walled gardens will have to provide address space to the home
  that will be used to talk to them.  A challenge to the walled
  garden people's thought process is that they might be thinking
  that they need 1-IP per customer, when in fact, they need to have
  at least a /60 per customer.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 



pgp2hhmly84ZD.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet Architecture & Interim Meeting

[Michael Richardson]

> "james" == james woodyatt  writes:
>> There will be wide area network providers who interwork with the
>> home network but do not provide global connectivity.  Two
>> mentioned so far are utility networks and 3g providers.  One of
>> the outputs of the wg should be to define how they should be
>> configured to perform their role without messing up Internet
>> communication.

james> Those utility networks have a fundamental problem that I
james> contend is beyond the scope and charter of HOMENET.

james> Utility networks of that sort do not provide transit to the
james> Internet default-free zone.  They must therefore obtain their
james> routes to residential networks bilaterally.  This implies
james> that these utility networks could be-- and would do well to
james> be-- numbered with ULA prefixes, and that they should use of

If you said, "ULA-Central" I would agree.
I do not want to debug random packets on someone's network without
whois.

>> A wg Chair from the Internet area did accuse me of "breaking the
>> Internet model" because the utility networks my company builds do
>> not provide global connectivity to users with our 100kb to the
>> node.

james> That's really not the problem, if you want my humble opinion.
james> The problem, I would say, is that these utility networks
james> insist on extending their private routing domains into our
james> home networks where they don't belong and they aren't
james> welcome.

It does break the *I*nternet model: the one where the ISPs control
everything like the telcos did before, and I need to beg to be allowed
to receive SYN packets.  Why do I care if it breaks the business plans
of some ISPs?   

But the IETF needs to spend more time worrying about the *Internet
Protocols* rather than just the *I*nternet.   

>> [...]  6. The lookup of foo.ispA.net works over either DNS and
>> returns the same IP address, but the application-layer content is
>> completely different (e.g., a "subscriber" view when connecting
>> over the ISP-A connection).

james> This is the basic problem faced by any multi-homed host,
james> e.g. a personal computer with a 3G interface and a Wi-fi
james> interface that are simultaneously active, along with a
james> split-tunnel VPN interface [or three] running on one or both
james> interfaces.

james> It is a problem for host operating systems and applications
james> developers.  I suggest HOMENET should steer well clear of it,
james> and just about every related problem that is too easily
james> conflated with it.

What is the set of problems left for homenet then?

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Multilink subnet routing (MLSRv2)

[Pascal Thubert (pthubert)]

Hi Ole

> we (as in homenet) do not want to require host changes.

And when hosts get smarter we (as in people living in homes) should
benefit from it. 

The case of plain hosts was long debated but it would have overloaded
the specs quite a bit. What we have so far:

The backbone router proxies ND between a L2 backbone and one or more
MLSN extensions; this allows a plain (classical) host connected to the
backbone to transparently reach devices that are located over the MLSN. 

Things get touchy if we want to support the case of a plain device that
would attach deep into the MLSN. You will not find that support
specified in current RPL or 6LoWPAN specs. There's a good start though
since RPL is designed to transport the material that is required by the
leaf router to build RAs, so for the purpose of forming an address we
can make believe that the plain host is really connected to the subnet. 

But the question is how the formed address can be DADed and routed. In
the absence of an explicit and maintained registration, the attachment
router/switch has to snoop and then proxy, either as an ND registration
or as redistribution into the routing protocol; If the device as a
unique, P2P connection with the router, then we can reuse what we learnt
in SAVI to maintain states in the router on behalf of the plain host. If
the device is connected to multiple routers and/or the device is mobile
and changes that point(s) of attachment over time, things can get a lot
messier.

> I also think the issues with flooding ND has been explored in RFC4903.

Thanks for pointing this. RFC 4903 explores a number of aspects, not
just ND, and in particular, TTL and link scope multicast. Specifically
focusing on ND, the scope and propagation of multicast already required
a new protocol. RPL started as an ND extension if you care to browse the
early drafts. The work that I listed below addresses for a large part
the problem of ND over MLSN, yet does a limited job for generic link
scope multicast. Then again there is a good start with the optimized
flooding with trickle that is good for all nodes and all routers, and a
support for a multicast tree along the RPL DAG for generic multicast.

Cheers,

Pascal

On Oct 10, 2011, at 9:33 , Pascal Thubert (pthubert) wrote:

> Hi Ole:
> 
> I think you're getting closer and closer to the models that were 
> discussed in RPL, 6LoWPAN and Autoconf.
> 
> There are several components to the solution that was proposed there:
> - capability to register an IPv6 address using ND extensions
> - capability to extend a subnet over multiple hops (RPL DIO prefix
> option)
> - capability to redistribute ND registration into  the MLSN routing 
> protocol
> - capability to use the ND registrar (and/or) the routing protocol for

> DAD
> - capability for the registrar to proxy ND over a backbone in order to

> interact with classical ND clients
> 
> See:
> http://tools.ietf.org/html/rfc5889
> http://tools.ietf.org/html/draft-ietf-6lowpan-nd
> http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router
> 
> cheers,
> 
> Pascal
> 
> 
> -Original Message-
> From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On 
> Behalf Of Ole Troan
> Sent: lundi 10 octobre 2011 00:38
> To: Erik Nordmark (nordmark)
> Cc: homenet@ietf.org
> Subject: [homenet] Multilink subnet routing (MLSRv2)
> 
> Erik, et al,
> 
> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it 
> hasn't really been described anywhere) as a method for numbering a 
> routed home. please let me be clear that I'm not convinced this is a 
> good idea. i.e. why not just get < /64?
> I do think we could get something working though.
> 
> routers can be in an arbitrary topology. all routers running a routing

> protocol.
> the site prefix (/64) is either advertised in the IGP with a new LSA 
> or proxying of RA messages is done (split horizon).
> a router advertises the same /64 prefix (in a PIO) on all of its 
> interfaces. L bit is 0.
> 
> the link model here is that all hosts are off link from each other.
> link-local scope is restricted to only the physical link. multicast 
> link-local scope as well.
> 
> a host uses SLAAC (or DHCP) to create an address, then does DAD as 
> normal. the first hop router uses it's routing topology database to 
> check for conflicts. similar mechanisms described in SAVI are used to 
> glean address information from the host. the SAVI binding database is 
> then used to inject host routes into the IGP.
> 
> this requires no flooding of ND, or any other changes to on-link 
> protocols for loop detection. no changes in hosts either.
> only downside is that it requires a host to have sent a packet of some

> form for the SAVI binding to be initiated.
> it might also be possible to support host mobility with the home with 
> this mechanism.
> 
> cheers,
> Ole
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jari Arkko]

Barbara,

Thank you very much for providing a concrete data point! I also agree with what 
you say below:


I'm sure some people would like to argue as to why this is bad, or it
shouldn't be done. I'm not going to get into that argument. That
argument is irrelevant. The fact is that it's very, very common.

I agree with those who say that we*don't*  need to make sure IPv4 works
everywhere that IPv6 works.
But I think it's an absolute requirement that IPv6 MUST work everywhere
that IPv4 works.


Jari

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

Re: [homenet] Does ND Proxy useful for homenet?

[Victor Kuarsingh]

>> On Sun, 9 Oct 2011, Shishio Tsuchiya wrote:
>>
>>> 2^64 host address space would be too enough for homenet.
>>
>>
>> I would just like to comment on this even though you retracted your question.
>>
>> As an ISP, I do not want to participate in a home with hundreds or thousands
of active IPv6 addresses that I need to keep state for. Most likely, when we
have central equipment participating in a home network, we'll implement a limit
on number of neighbours it'll allow on the subnet. Doing ND/NS a lot takes
resources.
>>
>> If customer wants to use more IPv6 addresses, we'll require them to get a
home router and PD address space to it to distribute the ND/NS load.
>>

>Agreed. But I think it is worth noting that nd-proxy is  practical in mobile
networks where each subscriber gets a unique /64.

>Mobile network attachment has popped up a few times in homenet discussions.


Yes, this will useful in a number of use cases with mobile attachment.
Tethering and other like operations come to mind.
A good reference is - draft-ietf-v6ops-3gpp-eps for mobile operation.

Victor K


>Cb
>> -- 
>> Mikael Abrahamssonemail: swm...@swm.pp.se
>>
>> ___
>> 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

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

Re: [homenet] Thoughts about routing

[STARK, BARBARA H]

The subset of tree topology where a consumer places ones router behind
another router is *extremely* common. Statistics I saw several years ago
suggested that probably about 60% of ADSL customers in the US use this
topology. The most common cause for this topology is where the service
provider supplies a free ADSL router with a single port to a subscriber,
and the subscriber then puts their own multi-port router behind that
router. The ADSL router is configured to do the PPPoE, and is also
configured to automatically provide whatever public IP address it gets
to whatever is behind it (via DHCPv4, as a sort of automatic DMZ
function -- the ADSL router also uses that public IP address for its
needs). The ADSL router is often set to provide only that one address,
and not to support a full network of devices. Which is why consumers are
forced to use their own router. This also tends to be how VoIP router +
consumer's wireless router topology works.

I'm sure some people would like to argue as to why this is bad, or it
shouldn't be done. I'm not going to get into that argument. That
argument is irrelevant. The fact is that it's very, very common. 

I agree with those who say that we *don't* need to make sure IPv4 works
everywhere that IPv6 works.
But I think it's an absolute requirement that IPv6 MUST work everywhere
that IPv4 works.

And this is a very common case where IPv4 works. When going to IPv6, the
ADSL router will also be the device that establishes the IPv6
connection. Because the credentials are the same as for IPv4, and the
secondary router doesn't have those credentials. And the consumer forgot
the credentials long ago, and doesn't remember how to configure this
stuff anyway.

IMO, I believe that the best approach would be to solve tree
generically. Which means that the probability of "tree network" would
actually be "common, perhaps 30th percentile" (dividing my "60% in ADSL
networks" by 2).
Barbara

> -Original Message-
> On 10/7/11 12:48 AM, Fred Baker wrote:
> > I suggested that the probability of use of each of the scenarios on
> slide 4 were
> >   single router network: 90th percentile
> >   tree network:  unusual
> >   multi-router:  perhaps 5th percentile
> >   multihomed:unusual
> 
> Fred,
> 
> are the above numbers based on any survey data?
> 
> Reason I'm asking is that I have two consumer devices with IPv4 NAT in
> my home (a VoIP box and a backup device) where the instructions said:
> 1. Insert between or existing router (or PC if you have no router) and
> the DSL/cable modem
> 2. Insert between your PC and your existing router (or modem if you
> have
> no router)
> 
> Those consumer instructions naturally result in a daisy-chain of IPv4
> RGs/NATs, which is a subset of a tree topology.
> 
> I can't be the only person who have a VoIP box or a Time Capsule.
> 
> Erik
> ___
> 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

Re: [homenet] Does ND Proxy useful for homenet?

[Cameron Byrne]

On Oct 9, 2011 11:16 PM, "Mikael Abrahamsson"  wrote:
>
> On Sun, 9 Oct 2011, Shishio Tsuchiya wrote:
>
>> 2^64 host address space would be too enough for homenet.
>
>
> I would just like to comment on this even though you retracted your
question.
>
> As an ISP, I do not want to participate in a home with hundreds or
thousands of active IPv6 addresses that I need to keep state for. Most
likely, when we have central equipment participating in a home network,
we'll implement a limit on number of neighbours it'll allow on the subnet.
Doing ND/NS a lot takes resources.
>
> If customer wants to use more IPv6 addresses, we'll require them to get a
home router and PD address space to it to distribute the ND/NS load.
>

Agreed. But I think it is worth noting that nd-proxy is  practical in mobile
networks where each subscriber gets a unique /64.

Mobile network attachment has popped up a few times in homenet discussions.

Cb
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
> ___
> 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

Re: [homenet] Multilink subnet routing (MLSRv2)

[Ole Troan]

Pascal,

we (as in homenet) do not want to require host changes.
I also think the issues with flooding ND has been explored in RFC4903.

cheers,
Ole


On Oct 10, 2011, at 9:33 , Pascal Thubert (pthubert) wrote:

> Hi Ole:
> 
> I think you're getting closer and closer to the models that were
> discussed in RPL, 6LoWPAN and Autoconf.
> 
> There are several components to the solution that was proposed there:
> - capability to register an IPv6 address using ND extensions
> - capability to extend a subnet over multiple hops (RPL DIO prefix
> option) 
> - capability to redistribute ND registration into  the MLSN routing
> protocol
> - capability to use the ND registrar (and/or) the routing protocol for
> DAD
> - capability for the registrar to proxy ND over a backbone in order to
> interact with classical ND clients
> 
> See:
> http://tools.ietf.org/html/rfc5889 
> http://tools.ietf.org/html/draft-ietf-6lowpan-nd 
> http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router
> 
> cheers,
> 
> Pascal
> 
> 
> -Original Message-
> From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On
> Behalf Of Ole Troan
> Sent: lundi 10 octobre 2011 00:38
> To: Erik Nordmark (nordmark)
> Cc: homenet@ietf.org
> Subject: [homenet] Multilink subnet routing (MLSRv2)
> 
> Erik, et al,
> 
> to expand on the ideas I presented on MLSR (or rather MLSRv2 as it
> hasn't really been described anywhere) as a method for numbering a
> routed home. please let me be clear that I'm not convinced this is a
> good idea. i.e. why not just get < /64?
> I do think we could get something working though.
> 
> routers can be in an arbitrary topology. all routers running a routing
> protocol.
> the site prefix (/64) is either advertised in the IGP with a new LSA or
> proxying of RA messages is done (split horizon).
> a router advertises the same /64 prefix (in a PIO) on all of its
> interfaces. L bit is 0.
> 
> the link model here is that all hosts are off link from each other.
> link-local scope is restricted to only the physical link. multicast
> link-local scope as well.
> 
> a host uses SLAAC (or DHCP) to create an address, then does DAD as
> normal. the first hop router uses it's routing topology database to
> check for conflicts. similar mechanisms described in SAVI are used to
> glean address information from the host. the SAVI binding database is
> then used to inject host routes into the IGP.
> 
> this requires no flooding of ND, or any other changes to on-link
> protocols for loop detection. no changes in hosts either.
> only downside is that it requires a host to have sent a packet of some
> form for the SAVI binding to be initiated.
> it might also be possible to support host mobility with the home with
> this mechanism.
> 
> cheers,
> Ole
> 
> ___
> 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

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

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 9, 2011, at 8:53 PM, Acee Lindem wrote:

> Correct, it uses the best or only configured IPv4 address in the context 
> (aka, virtual router). Of course, we'd want to use something else for true 
> auto-configuration. 

Yes. For my money, in the absence of an IPv4 configuration, that's probably 
derived from a MAC Address, a serial number, or something else that is an 
attribute of the bit of equipment. But apart from observing on possible 
sources, Jon Moy would probably put on an animated look and observe that the 
router id is a 32 bit number unique in the routing domain, not necessarily an 
address of any kind.

A tiny bit of history here. Back in 1991 when we were doing the testing that 
resulted in RFC 1246, we (the implementers of 23 different implementations, 
many of which were derivative from the Maryland Prototype, e.g. Rob Coltun's 
code) had a discussion about where the router id should come from, and I 
commented that I had doctored my implementation to select one of the IPv4 
addresses in the area. What I just described was the discussion that followed. 
Maybe everyone else had already made the same choice, or maybe they changed 
their code soon after, but using one of the IPv4 addresses in the area was 
suddenly a pretty common solution. :-)


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

Re: [homenet] Homenet Architecture & Interim Meeting

[Ray Hunter]

>  The example of electric meters is a trivial one but the same can 
apply to other things.


I can assure you that the requirements and IT issues surrounding smart 
electric meters are far from "trivial."


You talk about "the electric company" being singular and monolithic. In 
reality there are many separate parties with interests in obtaining 
access to that data and controlling that meter (the home owner, multiple 
production/ delivery companies, meter data management company, meter 
management company, high voltage distribution company, medium voltage 
distribution company, regulators, micro generation  ) That can add 
up to 15 different roles, and many different message types.


See e.g. /EBSII White Paper: "Smart European Energy Architecture"

or

http://www.google.nl/url?sa=t&source=web&cd=4&ved=0CC0QFjAD&url=http%3A%2F%2Fwww.esmig.eu%2Fnewsstor%2Fnews-file-store%2FEU-MeteringV4.pdf%2Fat_download%2Ffile&rct=j&q=EBSII%20White%20Paper%3A%20%E2%80%9CSmart%20European%20Energy%20Architecture%E2%80%9D&ei=JZ-STvnTLMmg-wbm6qHTCg&usg=AFQjCNGpFWhNfa1HeBA24wlVPwLEFB0T6A&sig2=CT0FCDXVmniyxMoSup9SPw&cad=rja


regards,
RayH

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

Re: [homenet] Multilink subnet routing (MLSRv2)

[Pascal Thubert (pthubert)]

Hi Ole:

I think you're getting closer and closer to the models that were
discussed in RPL, 6LoWPAN and Autoconf.

There are several components to the solution that was proposed there:
- capability to register an IPv6 address using ND extensions
- capability to extend a subnet over multiple hops (RPL DIO prefix
option) 
- capability to redistribute ND registration into  the MLSN routing
protocol
- capability to use the ND registrar (and/or) the routing protocol for
DAD
- capability for the registrar to proxy ND over a backbone in order to
interact with classical ND clients

See:
http://tools.ietf.org/html/rfc5889 
http://tools.ietf.org/html/draft-ietf-6lowpan-nd 
http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router

cheers,

Pascal


-Original Message-
From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On
Behalf Of Ole Troan
Sent: lundi 10 octobre 2011 00:38
To: Erik Nordmark (nordmark)
Cc: homenet@ietf.org
Subject: [homenet] Multilink subnet routing (MLSRv2)

Erik, et al,

to expand on the ideas I presented on MLSR (or rather MLSRv2 as it
hasn't really been described anywhere) as a method for numbering a
routed home. please let me be clear that I'm not convinced this is a
good idea. i.e. why not just get < /64?
I do think we could get something working though.

routers can be in an arbitrary topology. all routers running a routing
protocol.
the site prefix (/64) is either advertised in the IGP with a new LSA or
proxying of RA messages is done (split horizon).
a router advertises the same /64 prefix (in a PIO) on all of its
interfaces. L bit is 0.

the link model here is that all hosts are off link from each other.
link-local scope is restricted to only the physical link. multicast
link-local scope as well.

a host uses SLAAC (or DHCP) to create an address, then does DAD as
normal. the first hop router uses it's routing topology database to
check for conflicts. similar mechanisms described in SAVI are used to
glean address information from the host. the SAVI binding database is
then used to inject host routes into the IGP.

this requires no flooding of ND, or any other changes to on-link
protocols for loop detection. no changes in hosts either.
only downside is that it requires a host to have sent a packet of some
form for the SAVI binding to be initiated.
it might also be possible to support host mobility with the home with
this mechanism.

cheers,
Ole

___
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