Re: [homenet] Egress Routing Discussion: Baker model

[Fred Baker (fred)]

On Feb 22, 2013, at 9:35 AM, Michael Richardson  wrote:

> Fred, I'm not sure that foo-chairs@  needs to be CC'ed on this
> discussion?  Having not been through your documents yet...

I wanted them to see that the discussion was happening. They have each asked me 
to take some time with their working groups. In one case, that will be amusing; 
I chair v6ops, and ospf and v6ops conflict. Yes, that's a great reason for 
having a co-chair.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] automatic prefix management (OSPF or ISIS version)

[Fred Baker (fred)]

On Feb 22, 2013, at 1:54 PM, Michael Richardson  wrote:

> For a network where there is more than one ISP, is it acceptable for a CPE 
> that has decided that it is PREFIX1:0123::/64, to "randomly" decide to be 
> PREFIX2:0123::/64?

I don't see why not, at least in the home.

There is a case, which homenet hasn't thought much about that I'm aware of, 
which is renumbering a network. You'll notice in my draft that if the 
autoconfig prefix is withdrawn, I expect prefixes dependent on it to be 
withdrawn, and if stored in permanent storage, erased. The implication is that 
if the same prefix is then readvertised, there's a good chance that all of the 
subnet numbers will change. I know of at least one scenario where that would be 
considered a desirable characteristic. But I don't think that case is, at least 
at this point, a general case or one I would specify beyond a "MAY".
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Lorenzo Colitti]

On Fri, Feb 22, 2013 at 12:04 PM, Michael Thomas  wrote:

> I don't see how this requirement is different whether you use NPTv6+ULA or
>> dynamic global addresses. The only difference that I see is that in the
>> case where the machine has a global address, it knows what that address is
>> without having to ask a rendezvous server outside the network. In the case
>> where it only has ULA, it doesn't know what its address is unless it asks a
>> server.
>>
>
> Yes, NPTv6 as I recall begs the question of split resolvers and all of the
> ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong.


My point was more that that NPTv6 doesn't make that any easier, more
secure, or... anything, really. You still have to update the address
somewhere; all that NPTv6 gives you is that now the washing machine doesn't
know what its IPv6 address is. Right?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

Ted Lemon wrote:

On Feb 21, 2013, at 10:32 PM, David Lamparter  wrote:

We're using SLAAC (which AFAIK is reasonable to expect in a homenet?)
and a good percentage of our devices don't speak MDNS.  We didn't even
get as far as thinking about privacy addresses, we just failed to find
any reasonable way to get names to start with...


It's probably worth bearing in mind that the solution for your problem hasn't 
been standardized yet, nor is there even rough consensus on what the standard 
ought to look like, and so nobody's got it implemented in devices.

Basing our expectations on what the best we can do is on what we have now is a 
recipe for failure.   We should set our sights on doing it right, and accept 
that it won't be done right in the very earliest IPv6 homenets.


Well, if one of the requirements is that I be able to control my washing 
machine from across the continent,
I'm not sure why we're even screwing with mdns in this wg. And if that's not a 
requirement for this working
group, I have to ask which century it got chartered in.

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

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 21, 2013, at 10:32 PM, David Lamparter  wrote:
> We're using SLAAC (which AFAIK is reasonable to expect in a homenet?)
> and a good percentage of our devices don't speak MDNS.  We didn't even
> get as far as thinking about privacy addresses, we just failed to find
> any reasonable way to get names to start with...

It's probably worth bearing in mind that the solution for your problem hasn't 
been standardized yet, nor is there even rough consensus on what the standard 
ought to look like, and so nobody's got it implemented in devices.

Basing our expectations on what the best we can do is on what we have now is a 
recipe for failure.   We should set our sights on doing it right, and accept 
that it won't be done right in the very earliest IPv6 homenets.

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

Re: [homenet] NPTv6-only home networks

[David Lamparter]

On Thu, Feb 21, 2013 at 07:04:01PM -0800, Michael Thomas wrote:
> Lorenzo Colitti wrote:
> > On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas  > > wrote:
> > 
> > That's why we have ULAs and multiple prefixes.
> > 
> > 
> > ULA's are of limited use. I still want to start my washing machine
> > regardless of whether I'm at home or not.
> > 
> > 
> > And you'll know the current IPv6 address of that washing machine how?

[...snip..]

> Yes, NPTv6 as I recall begs the question of split resolvers and all of the
> ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong.
> 
> > Exactly. This group can specify alternatives, and if they're good 
> > enough, they'll get used.
> 
> I don't think that it's controversial to say that any solution that takes
> into account the many things we want to accomplish is going to be complex.
> Far more complex than what the average home-router-with-nat does right now.
> Rube Goldberg is not our friend here. It scares me.

Well, I wasn't able to find numbers on what percentage of CPEs is
Linux-based these days, but, in all honesty, I think if there is a
ready-made package for this, maybe even in OpenWRT, that will have a
major impact on proliferation of pretty much anything in the CPE area.

[...snip...]

> > I don't know about naming and security, but renumbering works using 
> > address deprecation (that's been in the spec since forever), and since 
> > it's covered by RFC6204 and there are conformance tests for it, devices 
> > with the appropriate logo will support it. Support for prefix delegation 
> > across multiple routers is spotty, and there's no way to make it work in 
> > arbitrary topologies, but for what it's worth, I run it at home and it 
> > does work (my operator-provided CPE supports DHCPv6 PD and all I needed 
> > to do was plug in an IPv6-capable CPE). source+destination based routing 
> > has been demonstrated to work.
> 
> Naming is the one thing I'm almost certain is out in la-la land even in the
> big leagues. For home I'm pretty certain that handwaving would be a generous
> description of the current state of affairs. And then there's securing things
> which is always great for a good belly laugh.

Indeed I have to agree on this one from practical experience.  We've
tried creating some kind of automatic IPv6 naming system at the local
hackerspace - with 2 network software developers, no less - and failed.
We're using SLAAC (which AFAIK is reasonable to expect in a homenet?)
and a good percentage of our devices don't speak MDNS.  We didn't even
get as far as thinking about privacy addresses, we just failed to find
any reasonable way to get names to start with...
(Ok, well, maybe MDNS would've been the way to go... but, being targeted
at local name resolution, this is nowhere near a turn-key solution for
accessing a washing machine from the internet either.)


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

Re: [homenet] Egress Routing Discussion: Baker model

[David Lamparter]

On Fri, Feb 22, 2013 at 09:41:42AM +0900, Lorenzo Colitti wrote:
> On Fri, Feb 22, 2013 at 4:23 AM, Fred Baker (fred)  wrote:
> 
> > This is that separate email. As I start, may I make the most direct
> > possible apology to my colleagues with other approaches. I'm going to say
> > that I think you're "wrong", and say why. That is in the spirit of open
> > discussion in which we have a technical disagreement. BTW, you should be
> > aware that I have a fair set of people who are telling me I'm wrong as
> > well, hopefully in the same spirit. Some of them are pretty irritated with
> > me, and I have gotten irritated with them.
> >
> 
> For what it's worth, as as a co-author of draft-troan-homenet-sadr-00, I
> don't think there is a disagreement. The draft cites your work, because we
> (or at least, I) think that the correct approach is in fact one where the
> routing protocol passes around source+destination routing pairs.

+1

> The reason why the draft also proposes a simplified version of SADR that
> integrates with prefix assignment protocol is that it's possible to
> implement this without having to make substantial changes to OSPF.
> Extending the routing protocols will be a long and possibly hard road, and
> we feel that the group should at least consider the possibility of an
> approach with better time-to-market and lower barrier to implementation -
> especially since the alternatives being proposed are hierarchical DHCPv6 PD
> and NPT66. The risk is that we make the perfect the enemy of the good and
> we end up with NPT66, which means that we will have thrown away the chance
> for end-to-end IPv6 connectivity and will have to build apps in IPv6 just
> as we did in IPv4 - forever trying to guess what their addresses are, which
> magic packet incancation will work, and which third-party server is the
> best to relay packets through.

I have the fear that this will come around and do some ass-biting.  This
is a very subjective opinion of course, but I think it's reasonable to
assume that if this ships, it will stick around for years to come.  Lots
of people never update their CPEs (which is obviously bad and leads to
security problems, but we can't will that away...)  So, even if we later
go the "full-blown" way, we'll have to be interoperable with those
will-be Simple SADR relicts.

> On the OSPF vs. IS-IS choice... well, if we had an implementation of ISIS
> that could run on home networking devices, or if there was at least one on
> the horizon, things would be very different.

There are in fact 2 implementations of IS-IS that may run on home
networking devices, in different states.

- BIRD seems to be interested in adding IS-IS due to interest from SPs.
  A branch exists, but not much progress has been made:
  [https://redmine.labs.nic.cz/projects/bird/repository?utf8=%E2%9C%93&rev=isis]

- (Disclaimer: I'm the Quagga maintainer)
  Quagga has had bad IS-IS support for a long time.  It has been
  overhauled and that overhaul was integrated in April 2012.  I've had
  the pleasure of declaring it "beta" in the last release, although
  we're still squashing bugs here and there.
  [http://savannah.nongnu.org/forum/forum.php?forum_id=7501]

Both BIRD and Quagga are readily available on OpenWRT derivatives and
should run reasonably fine on limited-resources CPE devices.  Both are
released under the GNU GPL (v2+).


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

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

Lorenzo Colitti wrote:
On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas > wrote:


That's why we have ULAs and multiple prefixes.


ULA's are of limited use. I still want to start my washing machine
regardless of whether I'm at home or not.


And you'll know the current IPv6 address of that washing machine how? If 
you assume renumbering, then the inevitable conclusion is  that the 
address at which you can reach the washing machine from outside your 
home will change. Therefore, something has to store that address 
somewhere that's accessible from outside the home, and it has to update 
it frequently enough that there are no significant outages.


Yes, that is the conclusion. The thing that I hold out some hope that we won't
be sucked down the NAT septic tank this time around is that the need to globally
address things on my home network won't be a geek-only oddity, but a real live
requirement that needs to be solved unlike NATv4.

Now do I have a lot of belief that this works well in real life? No, not really.
Particularly about naming, and the things being tossed around here give me
little hope that problem is even understood, let alone that solutions will be
forthcoming.

I don't see how this requirement is different whether you use NPTv6+ULA 
or dynamic global addresses. The only difference that I see is that in 
the case where the machine has a global address, it knows what that 
address is without having to ask a rendezvous server outside the 
network. In the case where it only has ULA, it doesn't know what its 
address is unless it asks a server.


Yes, NPTv6 as I recall begs the question of split resolvers and all of the
ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong.

Exactly. This group can specify alternatives, and if they're good 
enough, they'll get used.


I don't think that it's controversial to say that any solution that takes
into account the many things we want to accomplish is going to be complex.
Far more complex than what the average home-router-with-nat does right now.
Rube Goldberg is not our friend here. It scares me.

I think NAT became popular because users didn't want to pay ISPs twice 
to connect two devices. That was a pretty strong incentive. I think the 
incentives are much weaker with IPv6 now that residential ISPs provide 
at least a /64, and in most cases much more.


Yes, there were many reasons but the real point is that the IETF could scream
foul, issue rfc's (i'm not really sure it ever did, but...) and generally try
to stay relevant, but it didn't really matter. Utility fsvo "utility" 1,
architecture 0.


I don't know about naming and security, but renumbering works using 
address deprecation (that's been in the spec since forever), and since 
it's covered by RFC6204 and there are conformance tests for it, devices 
with the appropriate logo will support it. Support for prefix delegation 
across multiple routers is spotty, and there's no way to make it work in 
arbitrary topologies, but for what it's worth, I run it at home and it 
does work (my operator-provided CPE supports DHCPv6 PD and all I needed 
to do was plug in an IPv6-capable CPE). source+destination based routing 
has been demonstrated to work.


Naming is the one thing I'm almost certain is out in la-la land even in the
big leagues. For home I'm pretty certain that handwaving would be a generous
description of the current state of affairs. And then there's securing things
which is always great for a good belly laugh.

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

Re: [homenet] automatic prefix management (OSPF or ISIS version)

[Lorenzo Colitti]

On Fri, Feb 22, 2013 at 10:31 AM, Michael Richardson
wrote:

> I.e. the "0123" is identical for the two prefixes?
>

In the general case where the prefixes assigned by the operators are of
different lengths, it cannot be. Right?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] NPTv6-only home networks

[Lorenzo Colitti]

On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas  wrote:

> That's why we have ULAs and multiple prefixes.
>>
>
> ULA's are of limited use. I still want to start my washing machine
> regardless of whether I'm at home or not.


And you'll know the current IPv6 address of that washing machine how? If
you assume renumbering, then the inevitable conclusion is  that the address
at which you can reach the washing machine from outside your home will
change. Therefore, something has to store that address somewhere that's
accessible from outside the home, and it has to update it frequently enough
that there are no significant outages.

I don't see how this requirement is different whether you use NPTv6+ULA or
dynamic global addresses. The only difference that I see is that in the
case where the machine has a global address, it knows what that address is
without having to ask a rendezvous server outside the network. In the case
where it only has ULA, it doesn't know what its address is unless it asks a
server.


>  I don't like to think that NAT is inevitable but frankly the people
>> in this working group don't get to vote on that.
>>
>>
>> Actually they do. They have the freedom to specify alternatives, and
>> depending on how good a job they do, implementers may choose to use them.
>>
>
> Wishful thinking. NAT's didn't start with the blessing of IETF as I
> recall. They just
> happened. If the alternatives are too whacked out, history will repeat
> itself.


Exactly. This group can specify alternatives, and if they're good enough,
they'll get used.

I think NAT became popular because users didn't want to pay ISPs twice to
connect two devices. That was a pretty strong incentive. I think the
incentives are much weaker with IPv6 now that residential ISPs provide at
least a /64, and in most cases much more.


> Speaking to the title of this thread: has anybody actually
>
>> demonstrated such a thing end to end? It strikes me as
>> Frankensteinian when you get all of the body parts bolted together.
>>
>>
>> What thing exactly? Multiprefix multihoming? End-to-end connectivity in
>> general?
>>
>
> Yes, along with naming, security, prefix delegation across multiple
> routers, and isp's
> giving and withdrawing prefixes due to renumbering. I'm dubious that this
> has happened
> in real life with networks with people whose day job is to worry about
> such things, and
> I'd be astonished to hear such a thing has been shown to work on a home
> network.
>

I don't know about naming and security, but renumbering works using address
deprecation (that's been in the spec since forever), and since it's covered
by RFC6204 and there are conformance tests for it, devices with the
appropriate logo will support it. Support for prefix delegation across
multiple routers is spotty, and there's no way to make it work in arbitrary
topologies, but for what it's worth, I run it at home and it does work (my
operator-provided CPE supports DHCPv6 PD and all I needed to do was plug in
an IPv6-capable CPE). source+destination based routing has been
demonstrated to work.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Michael Thomas]

Lorenzo Colitti wrote:
On Fri, Feb 22, 2013 at 10:34 AM, Michael Thomas > wrote:


Sigh.


Sigh all you like, but I share Dave's skepticism that ISP's
renumbering my prefix willy-nilly and it just sort of works with
naming -- including addresses squirrelled away in places they ought
not be -- is going to work any time soon.


That's why we have ULAs and multiple prefixes.


ULA's are of limited use. I still want to start my washing machine regardless of
whether I'm at home or not.



I don't like to think that NAT is inevitable but frankly the people
in this working group don't get to vote on that.


Actually they do. They have the freedom to specify alternatives, and 
depending on how good a job they do, implementers may choose to use them.


Wishful thinking. NAT's didn't start with the blessing of IETF as I recall. 
They just
happened. If the alternatives are too whacked out, history will repeat itself.



Speaking to the title of this thread: has anybody actually
demonstrated such a thing end to end? It strikes me as
Frankensteinian when you get all of the body parts bolted together.


What thing exactly? Multiprefix multihoming? End-to-end connectivity in 
general?


Yes, along with naming, security, prefix delegation across multiple routers, 
and isp's
giving and withdrawing prefixes due to renumbering. I'm dubious that this has 
happened
in real life with networks with people whose day job is to worry about such 
things, and
I'd be astonished to hear such a thing has been shown to work on a home network.

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

Re: [homenet] Running code in Orlando

[Lorenzo Colitti]

On Fri, Feb 22, 2013 at 10:34 AM, Michael Thomas  wrote:

> Sigh.
>>
>
> Sigh all you like, but I share Dave's skepticism that ISP's renumbering my
> prefix willy-nilly and it just sort of works with naming -- including
> addresses squirrelled away in places they ought not be -- is going to work
> any time soon.


That's why we have ULAs and multiple prefixes.

I don't like to think that NAT is inevitable but frankly the people in this
> working group don't get to vote on that.
>

Actually they do. They have the freedom to specify alternatives, and
depending on how good a job they do, implementers may choose to use them.


> Speaking to the title of this thread: has anybody actually demonstrated
> such a thing end to end? It strikes me as Frankensteinian when you get all
> of the body parts bolted together.
>

What thing exactly? Multiprefix multihoming? End-to-end connectivity in
general?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Michael Thomas]

Lorenzo Colitti wrote:
On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht > wrote:


I still find the dynamicism required by renting ipv6 addresses to so
impact in so many aspects of the "sane usage of stuff like
printers", and naming, and the security model as to *demand* ipv6
nat in the home...


Sigh. 


Sigh all you like, but I share Dave's skepticism that ISP's renumbering my 
prefix
willy-nilly and it just sort of works with naming -- including addresses 
squirrelled
away in places they ought not be -- is going to work any time soon. I don't 
like to
think that NAT is inevitable but frankly the people in this working group don't 
get
to vote on that.

Speaking to the title of this thread: has anybody actually demonstrated such a 
thing
end to end? It strikes me as Frankensteinian when you get all of the body parts 
bolted
together.

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

[homenet] automatic prefix management (OSPF or ISIS version)

[Michael Richardson]

{possible resend}

Fred,

wrt:  draft-baker-ipv6-isis-automatic-prefix-00

for a network where there is more than one ISP, is it acceptable for a CPE
that has decided that it is PREFIX1:0123::/64 (and gone through the
process of advertising it and backing things off...), to "randomly"
decide to be PREFIX2:0123::/64 when it sees PREFIX2?

I.e. the "0123" is identical for the two prefixes?

This seems a desireable (but not required) property that all the
prefixes on a LAN are similar.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 





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

Re: [homenet] Running code in Orlando

[Lorenzo Colitti]

On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht  wrote:

> I still find the dynamicism required by renting ipv6 addresses to so
> impact in so many aspects of the "sane usage of stuff like printers", and
> naming, and the security model as to *demand* ipv6 nat in the home...


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

Re: [homenet] Egress Routing Discussion: Baker model

[Lorenzo Colitti]

On Fri, Feb 22, 2013 at 4:23 AM, Fred Baker (fred)  wrote:

> This is that separate email. As I start, may I make the most direct
> possible apology to my colleagues with other approaches. I'm going to say
> that I think you're "wrong", and say why. That is in the spirit of open
> discussion in which we have a technical disagreement. BTW, you should be
> aware that I have a fair set of people who are telling me I'm wrong as
> well, hopefully in the same spirit. Some of them are pretty irritated with
> me, and I have gotten irritated with them.
>

For what it's worth, as as a co-author of draft-troan-homenet-sadr-00, I
don't think there is a disagreement. The draft cites your work, because we
(or at least, I) think that the correct approach is in fact one where the
routing protocol passes around source+destination routing pairs.

The reason why the draft also proposes a simplified version of SADR that
integrates with prefix assignment protocol is that it's possible to
implement this without having to make substantial changes to OSPF.
Extending the routing protocols will be a long and possibly hard road, and
we feel that the group should at least consider the possibility of an
approach with better time-to-market and lower barrier to implementation -
especially since the alternatives being proposed are hierarchical DHCPv6 PD
and NPT66. The risk is that we make the perfect the enemy of the good and
we end up with NPT66, which means that we will have thrown away the chance
for end-to-end IPv6 connectivity and will have to build apps in IPv6 just
as we did in IPv4 - forever trying to guess what their addresses are, which
magic packet incancation will work, and which third-party server is the
best to relay packets through.

On the OSPF vs. IS-IS choice... well, if we had an implementation of ISIS
that could run on home networking devices, or if there was at least one on
the horizon, things would be very different.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Egress Routing Discussion: Baker model

[Michael Richardson]

Fred, I'm not sure that foo-chairs@  needs to be CC'ed on this
discussion?  Having not been through your documents yet...

>This is that separate email. As I start, may I make the most direct possible
>apology to my colleagues with other approaches.

It would be helpful for me if you identified the different approaches.

You have taken an approach that involves extending the LSA of ISIS
(easy according to you) and of OSPF (harder, due to lack of sub-TLV).
The fundamental approach is to flood the set of all link attributes and
then:
   > The route policy is that traffic is forwarded to a stated
   > destination if and only if it also matches the other specified
   > attributes.  

> Which brings us, I suppose, to the FIB. There are many ways a FIB can
> be designed, and I would expect every vendor to do it their own way;
> this is not a matter for standardization. However, to have the
> discussion, it seems important to at least mention some possible
> approaches. In appendices in the drafts, I mention two. They are far
> from the only two; they are two.  

this is completely akin to IPsec's RFC2401/4301's need to provide a
set of functional requirements on the SPD, but not actually specify how
to implement it thank you for bringing this up!

> So, I can have a FIB per PA prefix, put egress default routes only
> into the FIBs for their source prefixes, and put every single
> destination route into each FIB. That results in a potentially-large
> number of FIBs, each of which contains mostly-identical
> information. 

Worse perhaps is that the FIB's are mostly optimized to have large
number of routes, and that optimization is mostly wasted here, because
the homenet has perhaps nPA * nRouters subnets + default routes.

Meanwhile, the source address selection process in Linux is mostly
implemented as a linear search, although there is nothing requiring
this.

IPsec 2401/4301 has the same problem, and we would up ordering the SPD
rather than specifying the order of evaluation for the various
longest-prefix-match searches, port and protocol parts of the SPD.
Fortuantely, most IPsec has had such lackluster uptake that outside of
the contrived examples that I wrote as test cases, few ever run into a
situation where two gateways pick different tunnels for traffic in two
directions.   I point to Appendix B of RFC4301 as a way to turn ordered
entries into something that a PATRICIA trie/LPM engine can better deal
with.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 


















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

[homenet] Egress Routing Discussion: Baker model

[Fred Baker (fred)]

On Feb 22, 2013, at 6:22 AM, Fred Baker  wrote:

> In Atlanta, Mark asked Lorenzo and I to put together a draft of an approach 
> to source/destination, and especially egress, routing. I pulled together a 
> plan of attack that I applied to both IPv4 and IPv6, and to both IS-IS and 
> OSPF and sought review from a limited list including Lorenzo; this includes 
> capabilities for at least one other use case I'm looking at. Mark asked me to 
> cut that down to make things separately implementable (which they would be 
> anyway, but to make it apparent). So I have broken it into components.
> 
> ..
> 
> I have documented my approach, which provides the generalized concept, is 
> built into the routing protocols IS-IS and OSPF, and also addresses at least 
> one other "tagged routing" option, which is to look at flow labels.
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix
>  "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing
>  "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
>  "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
>  "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
>  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible
>  "Extensible OSPF LSAs", Fred Baker, 17-Feb-13
> 
> I'll say why I think mine is the correct approach in another email, as I 
> imagine my colleagues will for theirs. But the working group should consider 
> the question.


This is that separate email. As I start, may I make the most direct possible 
apology to my colleagues with other approaches. I'm going to say that I think 
you're "wrong", and say why. That is in the spirit of open discussion in which 
we have a technical disagreement. BTW, you should be aware that I have a fair 
set of people who are telling me I'm wrong as well, hopefully in the same 
spirit. Some of them are pretty irritated with me, and I have gotten irritated 
with them.

Two parts of the question here relate to "what problem do we think we're 
solving" and "how do we model the network". A third will be "how do we 
implement it in a router?"

Homenet, I believe, thinks it's solving "how do I provide egress routing with 
zero, or perhaps epsilon, configuration, using open source code in the cheapest 
possible implementation." That's laudable; that said, I do believe that egress 
routing is a requirement for any IPv6 network involving multiple 
provider-allocated prefixes, and that as a result this is something to be built 
into the base protocol. In OSPF terminology, it is sufficient to build on an 
AS-external-LSA if that's the only source/destination route to be considered 
(it is certainly a principal use case); for a general network, however, we 
don't generally carry a lot of AS-external information around. So we need, I 
think, the ability to use native default routes as well as AS-external default 
routes, which means that we also need to look at the intra-area-prefix-LSA and 
the inter-area-prefix-LSA. The problem, I argue, is how to tag a route with a 
set of attributes and apply a route policy to it. One possible att
 ribute is the source prefix that might be used by systems communicating with 
this destination, and there are other possible attributes. The route policy is 
that traffic is forwarded to a stated destination if and only if it also 
matches the other specified attributes. So, when we want to source/destination 
route to a specified egress, the destination in question is a default route 
(::/0), the source is the relevant PA prefix, and we are asking the network to 
build routes in the way it natively does so for traffic that has the specified 
set of attributes.

As to "how we model it", there are at least two possible approaches. When Jon 
Moy was first building what we now call OSPF, one of the problems that the 
Internet was dealing with was congestive collapse. There were several 
experiments, one of which I was involved in with Neil Bierbaum of NASNET, in 
which we wanted to send interactive traffic using paths that had relatively low 
delay, and high volume file transfer traffic on other paths that had high 
throughput. It was not unusual for those "high throughput" paths to also have 
long delay, such as through a geosynchronous satellite. The technology for 
doing this was originally documented, at least publicly, in RFCs 1131 and 1247, 
commented on in RFC 1812, and has evolved to RFC 4915's Multi-topology Routing; 
it was developed in parallel in IS-IS as well. The multi-topology model is 
based on the premise that routers and/or links differ from each other i

Re: [homenet] Egress Routing Discussion

[Michael Richardson]

> "fred" == fred  > writes:
fred> In Atlanta, Mark asked Lorenzo and I to put together a draft
fred> of an approach to source/destination, and especially egress,
fred> routing. I pulled together a plan of attack that I applied to
fred> both IPv4 and IPv6, and to both IS-IS and OSPF and sought
fred> review from a limited list including Lorenzo; this includes
fred> capabilities for at least one other use case I'm looking
fred> at. Mark asked me to cut that down to make things separately
fred> implementable (which they would be anyway, but to make it
fred> apparent). So I have broken it into components.

wow, thank you for this reading list.


-- 
Michael Richardson , Sandelman Software Works 




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

[homenet] Egress Routing Discussion

[Fred Baker (fred)]

In Atlanta, Mark asked Lorenzo and I to put together a draft of an approach to 
source/destination, and especially egress, routing. I pulled together a plan of 
attack that I applied to both IPv4 and IPv6, and to both IS-IS and OSPF and 
sought review from a limited list including Lorenzo; this includes capabilities 
for at least one other use case I'm looking at. Mark asked me to cut that down 
to make things separately implementable (which they would be anyway, but to 
make it apparent). So I have broken it into components.

So we have several drafts in play at this IETF.

Shu Yang documented his work in Quagga, in which he implemented 
source/destination routing as a multi-topology routing model.

http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing
  "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu
  Yang, Jianping Wu, Dan Wang, 18-Feb-13

Ole Troan and Lorenzo Colitti documented their model, which is strictly egress 
routing based on the OSPF AS-prefix-LSA and the assumption of automated prefix 
allocation. This is not multi-topology; it in effect tags the default route 
advertised as a route from an alternate universe.

http://tools.ietf.org/html/draft-troan-homenet-sadr
  "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole
  Troan, Lorenzo Colitti, 18-Feb-13

I have documented my approach, which provides the generalized concept, is built 
into the routing protocols IS-IS and OSPF, and also addresses at least one 
other "tagged routing" option, which is to look at flow labels.

http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix
  "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing
  "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
  "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
  "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible
  "Extensible OSPF LSAs", Fred Baker, 17-Feb-13

I'll say why I think mine is the correct approach in another email, as I 
imagine my colleagues will for theirs. But the working group should consider 
the question.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Brzozowski, John]

Since BnB is one night can we make provisions for the home net lab area to
be open all week?  Mark? Ray?

Seems like it would be worth it.  I am thinking all week would be ideal.
;)

=
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







-Original Message-
From: Dave Taht 
Date: Thursday, February 21, 2013 9:35 AM
To: John Jason Brzozowski 
Cc: David Lamparter , Michael Richardson
, "homenet@ietf.org Group" , Mark
Townsley , Jari Arkko , Lorenzo
Colitti 
Subject: Re: [homenet] Running code in Orlando

>
>
>
>I am primarily focused on demonstrating solutions to bufferbloat in my
>portion of bit's and bytes.
>
>But I note that the present CeroWrt build appears to have working dhcp-pd
>(I've successfully got /56 /60, /61/ /62 subnets from it), and assigning
>that to the 6+ internal interfaces, support for every other form of ipv6
>tunneling, the latest dnsmasq which has
> some good ways of bonding dns names to ipv6 s, support for routing
>ipv4 and ipv6 subnetworks over the quagga babel protocol (the two routers
>I'm demoing are meshed together at 5ghz)
>
>We had to fix a few nasty instruction traps in the ipv6 stack last month,
>but after doing that, I'm pretty pleased with the over-all performance
>and reliability - it survived the "thc" ipv6 tests handily, for example.
>Could use some more exaustive real-world
> testing, so, get it (for the wndr3700v2 and 3800 series)
>
>http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.5-2/
>
>We also have specialized  builds for the ubiquity nanostation m5 and
>picostation m2hp products deployed in the campground testbed.
>
>We still haven't done anything with distributing prefixes inside the home
>beside ahcp, and I still find the dynamicism required by renting ipv6
>addresses to so impact in so many aspects of the "sane usage of stuff
>like printers", and naming, and the security
> model as to *demand* ipv6 nat in the home... but I did not get around to
>implementing npt66 in this release!!
>
>
>(so those that would flame me for this opinion can hold off (pretty
>please!?) until perhaps I can go into the implementation details of all
>the many things that break today... with those that care. )
>
>In terms of interop, besides dhcp-pd and bufferbloat fixes, I'd rather
>like to see if these release can be made to work with ospfv6 on other
>devices. What else will be shown? The original homenet code was far too
>large to be usable on such a small device, but
> perhaps at least the ospf layer could be tried.
>
>And all that said, I'm rather totally buried with tests for, processing a
>ton of data from the field, and testing nfq_codel/bufferbloat. I just
>finished giving talks on that at MIT and Stanford on that stuff
>
>What's wrong with wifi?
>
>http://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be
>  
>Intro to codel and fq_codel:
>
>http://netseminar.stanford.edu/
>
>
>
>On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, John
> wrote:
>
>Statically assigning prefixes may enable testing but is not how homes will
>be provisioned in reality.
>
>=
>John Jason Brzozowski
>Comcast Cable
>m) 484-962-0060 
>e) john_brzozow...@cable.comcast.com
>o) 609-377-6594 
>w) www.comcast6.net 
>=
>
>
>
>
>
>
>
>-Original Message-
>
>From: David Lamparter 
>Date: Wednesday, February 20, 2013 9:41 PM
>To: John Jason Brzozowski 
>Cc: David Lamparter , Lorenzo Colitti
>
>, Michael Richardson >,
>"homenet@ietf.org Group" , Jari Arkko
>, Mark Townsley 
>Subject: Re: [homenet] Running code in Orlando
>
>
>>On Thu, Feb 21, 2013 at 04:17:06AM +, Brzozowski, John wrote:
>>> David Lamparter wrote:
>>> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote:
>>> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
>>> >> mailto:mcr%2bi...@sandelman.ca>>wrote:
>>> >>
>>> >> > Would/could another foot of such a network be on the IETF network?
>>> >> >
>>> >>
>>> >> If the IETF network didn't respond to DHCPv6 PD requests, it
>>>wouldn't be
>>> >> much use.
>>> >
>>> >Even without DHCPv6 PD on the remainder of the IETF network, it might
>>>be
>>> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating
>>>part
>>> >of the provider network.
>>>
>>> Why emulate it?  Is the intention here to test the the code on an
>>> enterprise or corporate network?
>>
>>The scope of the plugfest is the interior and border of the homenet.  To
>>get the border right, we need the service provider side of that border
>>in some form.  If the IETF network runs DHCPv6-PD, that is an usable
>>approximation.
>>
>>My suggestion was for the case that the IETF network won't be running
>>DHCPv6-PD.  In that case, the easiest way to make the IETF network
>>usable as one uplink for the hom

Re: [homenet] Running code in Orlando

[Dave Taht]

I am primarily focused on demonstrating solutions to bufferbloat in my
portion of bit's and bytes.

But I note that the present CeroWrt build appears to have working dhcp-pd
(I've successfully got /56 /60, /61/ /62 subnets from it), and assigning
that to the 6+ internal interfaces, support for every other form of ipv6
tunneling, the latest dnsmasq which has some good ways of bonding dns names
to ipv6 s, support for routing ipv4 and ipv6 subnetworks over the
quagga babel protocol (the two routers I'm demoing are meshed together at
5ghz)

We had to fix a few nasty instruction traps in the ipv6 stack last month,
but after doing that, I'm pretty pleased with the over-all performance and
reliability - it survived the "thc" ipv6 tests handily, for example. Could
use some more exaustive real-world testing, so, get it (for the wndr3700v2
and 3800 series)

http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.5-2/

We also have specialized  builds for the ubiquity nanostation m5 and
picostation m2hp products deployed in the campground testbed.

We still haven't done anything with distributing prefixes inside the home
beside ahcp, and I still find the dynamicism required by renting ipv6
addresses to so impact in so many aspects of the "sane usage of stuff like
printers", and naming, and the security model as to *demand* ipv6 nat in
the home... but I did not get around to implementing npt66 in this
release!!

(so those that would flame me for this opinion can hold off (pretty
please!?) until perhaps I can go into the implementation details of all the
many things that break today... with those that care. )

In terms of interop, besides dhcp-pd and bufferbloat fixes, I'd rather like
to see if these release can be made to work with ospfv6 on other devices.
What else will be shown? The original homenet code was far too large to be
usable on such a small device, but perhaps at least the ospf layer could be
tried.

And all that said, I'm rather totally buried with tests for, processing a
ton of data from the field, and testing nfq_codel/bufferbloat. I just
finished giving talks on that at MIT and Stanford on that stuff

What's wrong with wifi?

http://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be

Intro to codel and fq_codel:

http://netseminar.stanford.edu/



On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, John <
john_brzozow...@cable.comcast.com> wrote:

> Statically assigning prefixes may enable testing but is not how homes will
> be provisioned in reality.
>
> =
> John Jason Brzozowski
> Comcast Cable
> m) 484-962-0060
> e) john_brzozow...@cable.comcast.com
> o) 609-377-6594
> w) www.comcast6.net
> =
>
>
>
>
>
>
>
> -Original Message-
> From: David Lamparter 
> Date: Wednesday, February 20, 2013 9:41 PM
> To: John Jason Brzozowski 
> Cc: David Lamparter , Lorenzo Colitti
> , Michael Richardson ,
> "homenet@ietf.org Group" , Jari Arkko
> , Mark Townsley 
> Subject: Re: [homenet] Running code in Orlando
>
> >On Thu, Feb 21, 2013 at 04:17:06AM +, Brzozowski, John wrote:
> >> David Lamparter wrote:
> >> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote:
> >> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
> >> >> wrote:
> >> >>
> >> >> > Would/could another foot of such a network be on the IETF network?
> >> >> >
> >> >>
> >> >> If the IETF network didn't respond to DHCPv6 PD requests, it
> >>wouldn't be
> >> >> much use.
> >> >
> >> >Even without DHCPv6 PD on the remainder of the IETF network, it might
> >>be
> >> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating
> >>part
> >> >of the provider network.
> >>
> >> Why emulate it?  Is the intention here to test the the code on an
> >> enterprise or corporate network?
> >
> >The scope of the plugfest is the interior and border of the homenet.  To
> >get the border right, we need the service provider side of that border
> >in some form.  If the IETF network runs DHCPv6-PD, that is an usable
> >approximation.
> >
> >My suggestion was for the case that the IETF network won't be running
> >DHCPv6-PD.  In that case, the easiest way to make the IETF network
> >usable as one uplink for the homenet plugfest is to ask for a /52 to be
> >made available for the plugfest in some static way and then provide
> >DHCPv6-PD from that, running on some random PC box/laptop somewhere.
> >
> >Actually - controlling the DHCPv6-PD might be advantageous in order to
> >allow tinkering with it to see how the testbed reacts.
> >
> >
> >-David
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt

[Chris Donley]

On 2/21/13 1:46 AM, "Mattia Rossi" 
wrote:

>Hi Chris,
>
>reading the draft, it seems clear that it is bound to your specific
>CableLabs eRouter use case.
Just as our eRouter specification was relevant to the wider community as a
contribution to RFC 6204/bis, we believe that our updates to support
multirouter topologies are also relevant beyond the cable ecosystem.

>I haven't understood if this is just an informational draft, or whether
>you want to pursue it further and adapt the draft to create a standard.
This is informational.  We are bringing our updates to the IETF, in case
others can benefit from our work.  We expect to be able to demonstrate
this functionality in Orlando on OpenWRT routers - stop by and check it
out.

> 
>In the latter case, some thoughts:
>
>It's not clear, that it would work with all the scenarios outliend in
>section 3.2.2 of the homenet architecture
>(http://tools.ietf.org/html/draft-ietf-homenet-arch-07).
>E.g. how does it cover Multihoming? If an internal router gets two
>addresses, one from each prefix, and assuming no CER_ID, how do you
>ensure that the /48 check works, and it doesn't pick the first address,
>comparing it to the second prefix, and thus declaring the router a CER
>which it is not?
>I believe that's a non-issue, as the /48 check is done on a
>per-interface basis, but that's not documented in the draft.
>A multihoming section where you explain this, would be beneficial I think.
Multihoming is covered in Section 6 (Multiple ISPs). We believe that our
approach will cover the scenarios in the homenet arch document, as well as
some additional ones (e.g. 2 ISPs, 2 CERs, non-shared subnet e.g. For
VPNs). To your point, we could clarify that the /48 check is per prefix
per interface.
>
>I also don't like the "/48 check" notation, as it implies that ISP's
>hand out a /48 (even if stated otherwise in the text).
>If you call it "ISP prefix check" or "Delegated prefix check" would be
>better, as the principle is, that the ISP hands out an address to the
>CER which is different from the delegated prefix, while the CER hands
>out addresses from that prefix.
Thanks.  We'll consider it for a future version.
>
>Cheers,
>
>Mat



Chris
-- 
Chris Donley
CCIE, CISSP, SCiPM
Director - Network Technologies
CableLabs®
858 Coal Creek Circle
Louisville, CO 80027
303-661-3480 (v)






>
>Am 20.02.2013 20:38, schrieb Chris Grundemann:
>> Dear Homenet,
>>
>> CableLabs, in cooperation with our members and vendor companies, is
>> enhancing our eRouter specification to support multirouter home
>>networks.
>> As we have in the past, we are presenting our eRouter updates to the
>>IETF
>> in the spirit of sharing.  We believe that these enhancements meet the
>> principles of the homenet-arch document, while not relying on new
>>protocol
>> development.
>>
>> In addition, we are prototyping these enhancements, and are planning to
>> demonstrate them in Orlando.
>>
>> Cheers,
>> ~Chris
>>
>>
>>
>> On 2/16/13 8:27 AM, "internet-dra...@ietf.org"
>>
>> wrote:
>>
>>> A new version of I-D, draft-grundemann-homenet-hipnet-00.txt
>>> has been successfully submitted by Chris Donley and posted to the
>>> IETF repository.
>>>
>>> Filename:draft-grundemann-homenet-hipnet
>>> Revision:00
>>> Title:   A Near Term Solution for Home IP Networking (HIPnet)
>>> Creation date:   2013-02-15
>>> Group:   Individual Submission
>>> Number of pages: 22
>>> URL:
>>> 
>>>http://www.ietf.org/internet-drafts/draft-grundemann-homenet-hipnet-00.t
>>>xt
>>> Status:
>>> http://datatracker.ietf.org/doc/draft-grundemann-homenet-hipnet
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-00
>>>
>>>
>>> Abstract:
>>>Home networks are becoming more complex.  With the launch of new
>>>services such as home security, IP video, Smart Grid, etc., many
>>>Service Providers are placing additional IPv4/IPv6 routers on the
>>>subscriber network.  This document describes a self-configuring home
>>>router that is capable of operating in such an environment, and that
>>>requires no user interaction to configure it.  Compliant with
>>>draft-ietf-homenet-arch, it uses existing protocols in new ways
>>>without the need for a routing protocol.
>>>
>>>
>>>
>>> 
>>>
>>>
>>> The IETF Secretariat
>>>
>> ___
>> 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] Running code in Orlando

[Brzozowski, John]

Statically assigning prefixes may enable testing but is not how homes will
be provisioned in reality.

=
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







-Original Message-
From: David Lamparter 
Date: Wednesday, February 20, 2013 9:41 PM
To: John Jason Brzozowski 
Cc: David Lamparter , Lorenzo Colitti
, Michael Richardson ,
"homenet@ietf.org Group" , Jari Arkko
, Mark Townsley 
Subject: Re: [homenet] Running code in Orlando

>On Thu, Feb 21, 2013 at 04:17:06AM +, Brzozowski, John wrote:
>> David Lamparter wrote:
>> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote:
>> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
>> >> wrote:
>> >> 
>> >> > Would/could another foot of such a network be on the IETF network?
>> >> >
>> >> 
>> >> If the IETF network didn't respond to DHCPv6 PD requests, it
>>wouldn't be
>> >> much use.
>> >
>> >Even without DHCPv6 PD on the remainder of the IETF network, it might
>>be
>> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating
>>part
>> >of the provider network.
>> 
>> Why emulate it?  Is the intention here to test the the code on an
>> enterprise or corporate network?
>
>The scope of the plugfest is the interior and border of the homenet.  To
>get the border right, we need the service provider side of that border
>in some form.  If the IETF network runs DHCPv6-PD, that is an usable
>approximation.
>
>My suggestion was for the case that the IETF network won't be running
>DHCPv6-PD.  In that case, the easiest way to make the IETF network
>usable as one uplink for the homenet plugfest is to ask for a /52 to be
>made available for the plugfest in some static way and then provide
>DHCPv6-PD from that, running on some random PC box/laptop somewhere.
>
>Actually - controlling the DHCPv6-PD might be advantageous in order to
>allow tinkering with it to see how the testbed reacts.
>
>
>-David

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

Re: [homenet] Running code in Orlando

[Brzozowski, John]

Where the home has ethernet run to it?

=
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







-Original Message-
From: Michael Richardson 
Date: Wednesday, February 20, 2013 9:53 PM
To: John Jason Brzozowski 
Cc: David Lamparter , Lorenzo Colitti
, "homenet@ietf.org Group" , Jari
Arkko , Mark Townsley 
Subject: Re: [homenet] Running code in Orlando

>
>> "Brzozowski," == Brzozowski, John
>> writes:
>Brzozowski> Why emulate it?  Is the intention here to test the the
>code on an
>Brzozowski> enterprise or corporate network?
>
>Walled Garden :-)
>
>
>-- 
>Michael Richardson , Sandelman Software Works
>
>

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

Re: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt

[Mattia Rossi]

Hi Chris,

reading the draft, it seems clear that it is bound to your specific 
CableLabs eRouter use case.
I haven't understood if this is just an informational draft, or whether 
you want to pursue it further and adapt the draft to create a standard. 
In the latter case, some thoughts:


It's not clear, that it would work with all the scenarios outliend in 
section 3.2.2 of the homenet architecture 
(http://tools.ietf.org/html/draft-ietf-homenet-arch-07).
E.g. how does it cover Multihoming? If an internal router gets two 
addresses, one from each prefix, and assuming no CER_ID, how do you 
ensure that the /48 check works, and it doesn't pick the first address, 
comparing it to the second prefix, and thus declaring the router a CER 
which it is not?
I believe that's a non-issue, as the /48 check is done on a 
per-interface basis, but that's not documented in the draft.

A multihoming section where you explain this, would be beneficial I think.

I also don't like the "/48 check" notation, as it implies that ISP's 
hand out a /48 (even if stated otherwise in the text).
If you call it "ISP prefix check" or "Delegated prefix check" would be 
better, as the principle is, that the ISP hands out an address to the 
CER which is different from the delegated prefix, while the CER hands 
out addresses from that prefix.


Cheers,

Mat

Am 20.02.2013 20:38, schrieb Chris Grundemann:

Dear Homenet,

CableLabs, in cooperation with our members and vendor companies, is
enhancing our eRouter specification to support multirouter home networks.
As we have in the past, we are presenting our eRouter updates to the IETF
in the spirit of sharing.  We believe that these enhancements meet the
principles of the homenet-arch document, while not relying on new protocol
development.

In addition, we are prototyping these enhancements, and are planning to
demonstrate them in Orlando.

Cheers,
~Chris



On 2/16/13 8:27 AM, "internet-dra...@ietf.org" 
wrote:


A new version of I-D, draft-grundemann-homenet-hipnet-00.txt
has been successfully submitted by Chris Donley and posted to the
IETF repository.

Filename:draft-grundemann-homenet-hipnet
Revision:00
Title:   A Near Term Solution for Home IP Networking (HIPnet)
Creation date:   2013-02-15
Group:   Individual Submission
Number of pages: 22
URL:
http://www.ietf.org/internet-drafts/draft-grundemann-homenet-hipnet-00.txt
Status:
http://datatracker.ietf.org/doc/draft-grundemann-homenet-hipnet
Htmlized:
http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-00


Abstract:
   Home networks are becoming more complex.  With the launch of new
   services such as home security, IP video, Smart Grid, etc., many
   Service Providers are placing additional IPv4/IPv6 routers on the
   subscriber network.  This document describes a self-configuring home
   router that is capable of operating in such an environment, and that
   requires no user interaction to configure it.  Compliant with
   draft-ietf-homenet-arch, it uses existing protocols in new ways
   without the need for a routing protocol.


  




The IETF Secretariat


___
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