Re: [homenet] homenet naming drafts "terminology"

[Ole Troan]

Is this the same as a hidden primary name server?

Cheers 
Ole

> On 5 May 2021, at 21:09, Michael Richardson  wrote:
> 
> 
> Ted Lemon  wrote:
>>> On May 5, 2021, at 11:51 AM, Michael Richardson 
>>> wrote:
>>> 3) We would be happy to go with another term, but we don't want to
>>> invent another term.  So, if the DNS anycast operator has another
>>> term, then I'd go with it.
> 
>> Authority database?
> 
> I thought that you were asking who was an authoritive database of operators.
> Then I understood that you are suggesting "authority database" as the term.
> 
> Some ascii art, (so pick a sensible mono-spaced font, or use the archive 
> link):
> 
> .-.  .-.
> | S P | ---> | D M |\---\--\
> `-'  `-'|   |  |
>V   V  V
> .-. .. ..
> | Sec | | Sec| |Sec |
> `-' `' `'
> 
> S.P. = Stealth Primary
> Sec  = Secondary
> D M  = Distribution M*
> 
> Note that the "DM" is usually not listed as an NS, but rather,
> two or more "Sec" are what is listed.
> 
> So, maybe "Distribution Authority" would make us both happy.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> ___
> 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] Support for RFC 7084 on shipping devices...

[Ole Troan]

Hi Ted,

>> Are you saying there might be gaps in HNCP? Or things we could do to make it 
>> more deployable?
>> If it's just a matter of running code missing, I'm not sure defining 
>> anything else new in the IETF would help that problem.
> 
> There are definitely missing features from the protocol that I’d like to add. 
>   But I think the fact that the protocol isn’t deployed on a _single_ 
> commercially available router, and is not really usable on OpenWRT by a 
> non-expert, is an indication that there is substantial remaining work to do.  
>  Operations work is not out of scope for IETF; maybe I should have asked this 
> on v6ops.   We have historically said “not our problem,” but I don’t agree 
> that that’s the right answer.   If HNCP had really convincingly solved the 
> problem, we would not be seeing what we are seeing.

I believe HNCP has solved the technical problem it set out to do. Allow for an 
automatically configured, arbitrary topology network with multiple exits.
The deployment challenge of that is that every router must support HNCP and 
must support SADR.

>> I know why I haven't implemented HNCP on software I work on... and I also 
>> know that there aren't any very realistic alternatives either.
> 
> Can you say why that is?

Quite a few reasons, some which might be not relevant to your case of course.
 - the pendulum between distributed algorithms and centralized controllers is 
for the problems I'm working on largely towards the centralized side
 - it's quite a lot of work. it requires a new routing protocol, it requires a 
changed forwarding paradigm, and it requires integration with a lot of features
 - it does not support the case "permissionless extensions of the network".

>> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing 
>> and routers. I.e. what happens at the network layer.
> 
> You mean at the “internet layer,” I assume?

No, I mean the network layer. RA guard operates as a layer violating feature at 
the data-link layer.

>> If you are talking about what happens at the often integrated bridge CE 
>> devices have, then sure, they could implement RA Guard.
>> But having your additional router sending RAs across the homenet might not 
>> be a particularly good idea anyway.
> 
> Why not?   What would be a better idea?   I don’t mean to say that using RAs 
> in this way is ideal, but what’s the alternative that doesn’t involve the 
> vast complexity of per-host routing?

I don't understand how it would work. Add another router with it's own link. 
How would you get addresses for that link? Make them up from ULA? And then 
advertise that in an RA upstream with the MSR option?
That would put a lot of responsibility on the hosts of getting things "right".
And what if you added two of your routers, or connected them differently?

Per-host routing is in itself trivial and likely scales orders of magnitude 
further than you need. But there are problems with MLSR that are unsolved / not 
solved to my liking yet there.

>> Sounds like you need to set it up as a NAT.
> 
> I really hope you are just making a funny joke here.   But it’s not very 
> funny.   What I want is something that’s operationally simple, not something 
> with lots of moving parts that have to be kept track of.   NATs in particular 
> suck for any UDP-based protocol.

for "permissionless extensions of the network" there isn't much else than NAT.
Your other likely option is an ND proxy. If you are very sure that nothing else 
can be added to the network (we don't want to build a spanning tree protocol 
out of ND).

>> I wasn't thinking of doing it exactly like the 6lowpan does it.
>> Regardless I don't see why scaling should be problematic, are you planning 
>> to have millions of rapidly moving hosts on your shared /64 network?
> 
> If you have N devices on a single link on the other side of the router, then 
> when using either RA or a routing protocol, the amount of information you 
> need to propagate to get things working is very small: just a prefix and a 
> router.   If you can’t do that, then the amount of information you need to 
> propagate is at a minimum N units, and possibly K*N, for some not 
> insignificant factor K.
> 
> To be clear, the reason I’m concerned about this is that I’ve looked at 
> implementing it on OpenWRT, and it’s at least roughly doubling the complexity 
> of the work required, even if you can depend on using IPv6.   If you have to 
> use IPv4 on one side, then it’s even more complexity.   And it’s utterly 
> stupid complexity—it adds no value over subnetting.   Why add that to the 
> network?

Because you don't like the mechanisms for automated subnet assignment? ;-)
And no, I'm not suggesting we should do MLSRv2 as a competitor for HNCP. MLSRv2 
would also require an update to every router, and a network operator allowing 
extensions to the network.


> This is why I’m asking people if they have knowledge of what is actually 
> deployed.   I think t

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ole Troan]

 Homenet has solved the problem of self-configuring networks in arbitrary 
 topologies.
>>> 
>>> If that were true, I wouldn’t be asking this question.  We’re still 
>>> chugging along, but we don’t have something that nay router vender could 
>>> even consider shipping right now. There isn’t enough participation in 
>>> homenet anymore for us to really iron out the kinks.  Certainly if I could 
>>> count o homenet being present in routers in the home, we wouldn’t be having 
>>> this conversation! :)
>> 
>> Since this was sent to an IETF list I assumed you were focused on standards. 
>> (And presumably also running code). :-)
> 
> It’s the running code that’s the problem.  What I’m hunting around for is 
> whether there are some things we need to do that we haven’t yet done.   I 
> wish I could say “just turn on Homenet and everything will be fine,” but we 
> aren’t in a position to say that yet.   If people are feeling satisfied that 
> homenet is “done,” we (the IETF, and the Internet community in general) have 
> a problem.
> 
> We’d been tempted to punt on this because there are perfectly good commercial 
> solutions that solve this problem with L2 bridging, but those don’t work when 
> you need to route between WiFi and e.g. 6lowpan networks.

Are you saying there might be gaps in HNCP? Or things we could do to make it 
more deployable?
If it's just a matter of running code missing, I'm not sure defining anything 
else new in the IETF would help that problem.

I know why I haven't implemented HNCP on software I work on... and I also know 
that there aren't any very realistic alternatives either.

 - single router and bridging (7084)
>>> 
>>> If it doesn’t filter RA, and I control the second router, I’m okay, right?
>> 
>> Well, yes it isn't a router at that point, it's a bridge.
> 
> The reason I mentioned this particular problem is that I’ve heard reports of 
> 7084 routers implementing RA guard, which sort of makes sense, but it totally 
> breaks this use case.

RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing and 
routers. I.e. what happens at the network layer.
If you are talking about what happens at the often integrated bridge CE devices 
have, then sure, they could implement RA Guard.
But having your additional router sending RAs across the homenet might not be a 
particularly good idea anyway.
Sounds like you need to set it up as a NAT.

 - arbitrary topology plug and play (homenet)
>>> 
>>> Yes, that’s homenet.   It would really help if folks who think homenet is 
>>> done would try to deploy it in their home using OpenWRT and see how it 
>>> goes.   Seriously.   This is not a solved problem.   We’re maybe 50-60% of 
>>> the way there at this point.   I’ve been trying to make progress on this 
>>> ever since HNCP was declared done, and occasionally get collaboration, and 
>>> indeed we may be begining to make progress agan, but we could definitely 
>>> use more participation if there are folks in 6man who want this to work and 
>>> imagine that it already does.
>> 
>> The notion of "permissionless extensions of the network" is still somewhat 
>> unresolved. HNCP allows for that, but as we know it's not well 
>> supported/deployed. I had some hopes for multi-link subnet routing 
>> (implemented how it was originally intended, not as spanning tree in ND). 
>> But I have never gotten around to flesh that out in detail. Pascal has done 
>> various stuff in this space for lowpan, which may be something to build on.
>> 
>> The MLSR idea is basically a /64 shared across all links. Hosts register 
>> with routers using ARO (or DHCP). Routers advertise host routes in a routing 
>> protocol between themselves. The tricky parts are of course detecting when 
>> hosts go away, detecting movement and so on.
> 
> I’ve seen this.   It’s how the 6lowpan folks seem to have defined their 
> “routing."   But scalability is horrible, and when I’ve looked at doing an 
> implementation, it’s obviously ridiculously harder than just publishing an 
> RA.   And it’s particularly hard if there’s no IPv6 on North Network.So 
> if there’s a way to get IPv6 to work in this case, that seems like a better 
> option.

I wasn't thinking of doing it exactly like the 6lowpan does it.
Regardless I don't see why scaling should be problematic, are you planning to 
have millions of rapidly moving hosts on your shared /64 network?

>> A side meeting in Singapore perhaps?
> 
> I’m not going to be in Singapore—I just can’t justify the carbon footprint.   
> I do think we ought to have a deeper discussion about this, though.   Maybe a 
> “virtual interim”?   If there’s interest, I’d be happy to organize this.   
> I’d also be happy to attend a side meeting in Singapore remotely, but our 
> experience with that thus far has been pessimal, and I don’t think a fix is 
> planned for Singapore (unless I just haven’t heard about it).


Cheers,
Ole
___
h

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ole Troan]

Ted,

>> Homenet has solved the problem of self-configuring networks in arbitrary 
>> topologies.
> 
> If that were true, I wouldn’t be asking this question.  We’re still chugging 
> along, but we don’t have something that nay router vender could even consider 
> shipping right now.  There isn’t enough participation in homenet anymore for 
> us to really iron out the kinks.  Certainly if I could count o homenet being 
> present in routers in the home, we wouldn’t be having this conversation! :)

Since this was sent to an IETF list I assumed you were focused on standards. 
(And presumably also running code). :-)

>> Unless someone goes to lengths describing exactly how this is supposed to 
>> work, the idea of "simplifying" the homenet solution sounds like a recipe 
>> for failure.
> 
> I tend to agree, but wasn’t proposing that.   I was really just trying to 
> solve the very specific problem of how I do IPv6 routing in the case I 
> described, given the hardware that is likely to be present in the home.
> 
>> How are you going to tell the customers that you can only plug in devices in 
>> particular topologies and in particular ways.
> 
> The customer already has a router.   Suppose I want to add a router with a 
> bunch of devices behind it, and  I know the router I’m adding will never have 
> a second layer behind it.   Can I get it to work?   That’s the problem.
> 
>> - single router and bridging (7084)
> 
> If it doesn’t filter RA, and I control the second router, I’m okay, right?

Well, yes it isn't a router at that point, it's a bridge.

> 
>> - arbitrary topology plug and play (homenet)
> 
> Yes, that’s homenet.   It would really help if folks who think homenet is 
> done would try to deploy it in their home using OpenWRT and see how it goes.  
>  Seriously.   This is not a solved problem.   We’re maybe 50-60% of the way 
> there at this point.   I’ve been trying to make progress on this ever since 
> HNCP was declared done, and occasionally get collaboration, and indeed we may 
> be begining to make progress agan, but we could definitely use more 
> participation if there are folks in 6man who want this to work and imagine 
> that it already does.

The notion of "permissionless extensions of the network" is still somewhat 
unresolved. HNCP allows for that, but as we know it's not well 
supported/deployed. I had some hopes for multi-link subnet routing (implemented 
how it was originally intended, not as spanning tree in ND). But I have never 
gotten around to flesh that out in detail. Pascal has done various stuff in 
this space for lowpan, which may be something to build on.

The MLSR idea is basically a /64 shared across all links. Hosts register with 
routers using ARO (or DHCP). Routers advertise host routes in a routing 
protocol between themselves. The tricky parts are of course detecting when 
hosts go away, detecting movement and so on.

A side meeting in Singapore perhaps?

>> - manually configured (meaning ansible, scripts or whatever automation 
>> solution external to the routers themselves).
> 
> Yech.   That’s not an option.  :]

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ole Troan]

Mikael,

>> RFC7084 does not have any support for internal routers.
> 
> While this is true, OpenWrt does support DHCPv6-PD within the home, out of 
> the box. I also have a report of AVN Fritzbox supporting sub-PD without 
> additional configuration.
> 
> In all devices I've looked at the WAN is WAN, it comes up with firewalls on, 
> requests PD etc, and if it doesn't get it then there is no GUA IPv6 on LAN.
> 
> In my opinion the work in homenet could be leveraged into an operational 
> document where recommendations on what parts of homenet could be easily 
> implemented to make it work within a home (without implementing everything), 
> thinking primarily of "firewall off" and "service discovery proxy on". If no 
> PD was available, turn ethertype 0x86dd bridging on between LAN and WAN. I 
> guess we would still need to do NAT44 because without HNCP there wouldn't be 
> a route to the IPv4 network on LAN of the "sub-router".
> 
> It would however mean that a printer on the sub-router LAN could be reached 
> over IPv6. In order for this to happen without HNCP then this sub-router 
> would need to send RAs on its WAN announcing reachability to its LAN IPv6 
> prefix (either GUA+ULA if PD is available, otherwise just ULA). I have never 
> seen RA guard or similar functions in residential equipment, so I would 
> expect this to work.

There has been multiple proposals in that direction.
None of them succeeded, because they left too many corner cases "undefined".

Homenet has solved the problem of self-configuring networks in arbitrary 
topologies.

Unless someone goes to lengths describing exactly how this is supposed to work, 
the idea of "simplifying" the homenet solution sounds like a recipe for 
failure. How are you going to tell the customers that you can only plug in 
devices in particular topologies and in particular ways.

- single router and bridging (7084)
- arbitrary topology plug and play (homenet)
- manually configured (meaning ansible, scripts or whatever automation solution 
external to the routers themselves).

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ole Troan]

Ted,

[top posting]

RFC7084 does not have any support for internal routers. 

Futher:
It might just be the way you describe the use cases, there seems to be a 
misconception about how routers work with regards to ND “advertisements”. ND is 
not a routing protocol. 

Hierarchical PD which you also allude to, was proposed, has limitations and was 
not standardized. That why HNCP was done. 

If you have a set of rfc7084 routers I believe you are left with manual 
configuration of prefixes and either manually configured static routing or RIP. 

Cheers 
Ole

> On 4 Oct 2019, at 02:40, Ted Lemon  wrote:
> 
> (If you got this as a Bcc, it’s because I am hoping you can contribute to 
> the discussion, but might not be on the mailing list to which I sent the 
> question, so please answer on-list if you are willing.)
> 
> I’ve been involved in some discussions recently where the question has come 
> up: how good is support for RFC7084 in shipping routers?   And what gaps 
> exist in RFC7084 that could cause problems?   And in cases where RFC7084 
> support either isn’t present, or isn’t useful because no IPv6 or because ISP 
> is delegating a /64, what things might work and what things might not, if we 
> want bidirectional reachability between two separate network links in the 
> home.
> 
> So for example, suppose we have "CE Router," which supports RFC7084, 
> including prefix delegation.  And we have "Internal Router" on that network 
> requests a delegation, and gets a prefix from the CE router.  Presumably that 
> prefix is out of a larger prefix that CE Router got from the ISP.  Great so 
> far.  Let’s call the network on the southbound interface of Internal Router 
> “South Network”. Let’s call the network on its northbound interface, which is 
> also the network on CE router’s southbound interface, “North Network.”
> 
> viz:
> 
>ISP
> |
> CE Router
> |
> North Network
> |---+--+-|
> |  |
>   Internal Router  + Node A
> |
> South Network
> |---+---+|
> |
>   Node B ---+
> 
> 
> If I want hosts on South Network to communicate with hosts on North Network, 
> what do I have to do?   Should Internal Router publish an RA on its 
> northbound interface?   What is the likelihood of that being filtered by the 
> network?   If packets for South Network are forwarded through CE Router, will 
> it forward them on to Internal Router, forward them north, or drop them?
> 
> Similarly, suppose we have a network where unfortunately PD Isn’t available 
> internally, but IPv6 is present on the northbound interface of the internal 
> node and southbound interface of the CE router.   Suppose further that 
> Internal Router allocates itself a ULA prefix and advertises that as 
> reachable and on-link on its southbound interface, and as reachable but not 
> on-link on its northbound interface.   Will that be blocked at layer 2 by CE 
> Router?   I’m sort of assuming here that the CE router is managing the North 
> Network link, which is probably WiFi.
> 
> Okay, now what if there’s no IPv6 support on CE Router or being provided by 
> CE router on North Network.   Suppose Internal Router allocates a ULA and 
> allocates two /64s out of the ULA, one of which is advertised as reachable on 
> its northbound interface and on-link on its southbound interface, and a 
> second of which is advertised as on-link on its northbound interface and 
> reachable on its southbound interface.
> 
> Fourth possibility: Node A is manually configured with an IPv6 address on a 
> prefix that Internal router is advertising as reachable on its southbound 
> interface, but which is not advertised on South Network because of filtering. 
>  Node B has an address on a prefix that Internal Router is advertising as 
> on-link on its southbound interface.   Node A has a static route configured 
> through Internal Router to the second prefix.   Is there any reason to think 
> that traffic between Node A and Node B will be filtered at layer 2 by CE 
> Router, assuming that traffic on North Network is all going through CE Router?
> 
> The goal here is to have bidirectional reachability between the two nodes on 
> IPv6 using either a global prefix or a ULA.  The concern is that something 
> could prevent each of these cases from working.   What I’m really curious 
> about is whether people have experience with doing communications of this 
> type using actual routers that ISPs are shipping.   Is this “internal 
> network” scenario part of acceptance testing for thes

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

> "A host SHOULD select a "default gateway" for each prefix it uses to
>   obtain one of its own addresses.  That router SHOULD be one of the
>   routers advertising the prefix in its RA.  As a result of doing so,
>   when a host emits a datagram using a source address in one of those
>   prefixes and has no history directing it otherwise, it SHOULD send it
>   to the indicated "default gateway"."
> 
> The question is to which one (if there are multiple): this might be important
> for e.g. fail-over cases or if you want to dynamically optimize away that 
> extra
> hop you mention.
> 

yes, that text should be changed to accommodate multiple default routers.
ref rfc4311.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

Mikael,

>>> For DHCPv6 these contraints do not apply anymore. That's what I'm trying to 
>>> figure out, how do we handle these IA_NAs and IA_PDs that are not within an 
>>> on-link RA being sent for that prefix.
>> 
>> I take it IA_PD was included above by mistake.
> 
> No.

an IA_PD prefix is by definition not assigned to the link between RR and DR.

>>> This is definitely not a configuration error, it's perfectly valid to hand 
>>> out single address using DHCPv6 IA_NA that isn't covered by an off-link or 
>>> on-link prefix.
>> 
>> true. but I’m not sure what bearing that has with the host rule in question.
>> I’m also wondering if you are making a wrong assumption of what an L=0 PIO 
>> entails.
> 
> I don't know. Am I?
> 
> I still don't understand what a host with an IA_NA or IA_PD that isn't 
> covered by an on-link PIO should do with a packet sourced from those 
> IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case.

are you talking about something different than 3633 DHCPv6 prefix delegation?

if the SA doesn’t match a PIO on link, then the next-hop on that interface is 
chosen like it is today.

if you’re inventing new stuff like host IA_PD derived addresses, then that’s 
something someone has to specify.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

Mikael,

in the land of contrived examples! :-)
this working groups answer to the below is make this a homenet and run HNCP. 
then the host rule enhancement isn’t used.
in any case let me try to reply below, although I’m quite confused about the 
example.

>> two PIO’s of different length on the link sounds like a configuration error.
> 
> Then I must still be missing something.
> 
> Example time:
> 
> A   B+-+F
> +   +
> |   |
> ++-++
> | |
> + +
> C D
>   +
>   |
>   +
>   E
> 
> A, B and D are routers. A has received a /56 from ISPA. D has been delegated 
> a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising a /64 from 
> ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A is also 
> advertising ISPA /56 as off-link to indicate that it'll handle the entire /56.

currently, advertising a PIO with L=0 isn’t a routing advertisement (“handle 
the prefix”?). it only affects a hosts prefix list and how it does onlink 
determination for addresses in that prefix. i.e. a host would first chose D and 
NH, then find a suitable source.
with the new rule, the PIO becomes more like a source constrained route. “for 
any source address matching prefix in PIO, send traffic to me”.

I don’t understand what you would gain from the ISPA/56 PIO over the ISPA/64 
you’d have in C already.

> Now, C takes itself a couple of addresses from the ABCD /64 (because A=1) and 
> does DHCPv6 IA_NA. A then hands it an address from outside the /64 (because 
> that was configured for some reason). A has a /120 route pointing to its 
> interface that ABCD sits on, so that this DHCPv6 IA_NA works (because it's 
> outside the on-link /64).
> 
> D is a RFC7084 router and has requested IA_PD from A and received another 
> /64, which it then uses to put on the DE link.
> 
> Now, do we want D to do anything to tell C that E is reachable through D? 
> Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing and 
> let all traffic from C to D bounce via A? Do we want A to in some way 
> announce the delegated /64 IA_PD prefix?

1) run homenet / routing protocol
2) absolutely not
3) RIO with router lifetime of 0 could work but geez this is what homenet solves
4) yes
5) no

> What do we want A to do, should it announce the /120 as off-link? On-link 
> might make sense in this case.

that would only affect hosts on the ABCD link. D would still send all traffic 
for the /120 to A (as default route)

> B has F behind it, I guess we want this to get an address as well, from ISPA 
> prefix. Do we want B to send out an RIO for this /64?

you want B to run homenet.

> So for C, the world view might now look like this:
> 
> /56 RIO or PIO (depending on what we want to do) for ISPA prefix

I don’t see that you need either.

> /64 on-link PIO from A for the on-link ABCD /64 prefix

yes.

> /120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix

possibly. probably not needed.

> /64 RIO (?) from D for its DE /64
> /64 RIO (?) from B for its BF /64
> 
> Or do we want above RIOs to be off-link PIOs instead?

they would be RIOs. since you want destination routes, and not source routes.

in (D,S) SADR notation. a RIO:

(DE/64, *)

while PIO:

(::/0, DE/64)

please use homenet protocols. don’t build networks like this!

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

Mikael,

>> Ole, Mikael, could either of you please summarise the discussion you're 
>> having for us mere mortals?  I don't understand what problem you're trying 
>> to solve, and I don't understand why you're distinguishing between SLAAC and 
>> DHCPv6.
> 
> Because a DHCPv6 IA_NA and DHCPv6 IA_PD doesn't have to be covered by an 
> on-link prefix.
> 
> You don't get any SLAAC based addresses without an on-link RA for the prefix 
> with A=1. So this is obvious that there needs to be an RA sent.

RA’s are sent regardless of DHCP or SLAAC.
you can do SLAAC with A=1, L=0.

> For DHCPv6 these contraints do not apply anymore. That's what I'm trying to 
> figure out, how do we handle these IA_NAs and IA_PDs that are not within an 
> on-link RA being sent for that prefix.

I take it IA_PD was included above by mistake.


> This is definitely not a configuration error, it's perfectly valid to hand 
> out single address using DHCPv6 IA_NA that isn't covered by an off-link or 
> on-link prefix.

true. but I’m not sure what bearing that has with the host rule in question.
I’m also wondering if you are making a wrong assumption of what an L=0 PIO 
entails.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

Juliusz,

>>> “In SA, DA, NH selection, prefer the NH that has advertised a PIO
>>> covering the SA”
> 
> It took me a while to decode that.  If anyone else is as stupid as I am,
> here's the translation
> 
>  When selecting the (source, destination, next-hop) triple among
>  available routes for a given destination prefix, prefer one whose
>  next-hop is a router that sent an RA with a prefix that covers the
>  source address under consideration.

thanks for the readable version! ;-)
now, can you please write one for hosts that only have a Default Router List 
(as in no routing table).
(I don’t object if we only describe the conceptual host model for type C (4191) 
hosts though.

> Ole, Mikael, could either of you please summarise the discussion you're
> having for us mere mortals?  I don't understand what problem you're trying
> to solve, and I don't understand why you're distinguishing between SLAAC
> and DHCPv6.

I’ll try.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

Mikael,


> Your document describes (in my opinion) desireable behaviour for devices 
> going forward. I would like to see text for DHCPv6 as well, both IA_NA 
> and IA_PD, if the same kind of behaviour can work there somehow. This is 
> out of scope for homenet though.
 
 the rule applies regardless of how the addresses have been assigned.
>>> 
>>> Yes, but how will the router signal that it'll handle addresses for a 
>>> certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is 
>>> being assigned, but that isn't onlink?
>>> 
>>> Advertising that /56 as an off-link prefix hasn't historically said "I'll 
>>> handle Internet traffic for source addresses within all prefixes that I 
>>> announce, both offlink and on-link". Perhaps we can say that it does, but 
>>> it's not obvious to me that there are no corner cases for this that'll 
>>> break things.
>> 
>> the rule we are proposing is something like:
>> “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering 
>> the SA”
> 
> Check. And PIO here can be RIO as well?

no, I don’t think it can. the RIO says nothing about the link itself.

> What about if there are several PIO/RIOs of different size, do we do longest 
> matching on them to prefer one? Or shortest because the guy with the shortest 
> prefix (not /0) is more likely to be the one closest to the uplink?

two PIO’s of different length on the link sounds like a configuration error.

>> can you construct an example where the rule breaks things and that not 
>> having the rule wouldn’t?
> 
> No, I am still trying to figure out exactly what is being proposed. Next step 
> is to try to come up with something that'll make things break.

good. ;-)

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

Mikael,

>>> Your document describes (in my opinion) desireable behaviour for devices 
>>> going forward. I would like to see text for DHCPv6 as well, both IA_NA and 
>>> IA_PD, if the same kind of behaviour can work there somehow. This is out of 
>>> scope for homenet though.
>> 
>> the rule applies regardless of how the addresses have been assigned.
> 
> Yes, but how will the router signal that it'll handle addresses for a certain 
> prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being 
> assigned, but that isn't onlink?
> 
> Advertising that /56 as an off-link prefix hasn't historically said "I'll 
> handle Internet traffic for source addresses within all prefixes that I 
> announce, both offlink and on-link". Perhaps we can say that it does, but 
> it's not obvious to me that there are no corner cases for this that'll break 
> things.

the rule we are proposing is something like:
“In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the 
SA”

the subnet model in IPv6 assumed that all routers on a link had equal 
reachability. this rules solves the case where there are two routers with 
different reachability (and addressing) on a single link. currently hosts that 
don’t do implement this, typically suffer from long time outs and broken 
connectivity.

with the above rule I don’t see how offlink/onlink or DHCPv6 makes any 
difference. if there isn’t a PIO, well then the host is left uninformed.

can you construct an example where the rule breaks things and that not having 
the rule wouldn’t?

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Ole Troan]

> I am interested to learn what people think about whether equal-cost 
> multi-path routes are needed in homenet.  Given the previous discussion about 
> parallel wireless links - which I know I have in my house and can't use - 
> I've been wondering if these have been considered.
> 
> ECMP is critical in the data-center and backbone, but I'm interested in 
> seeing what the reasoning is as to why it isn't or is needed in the homenet 
> scenarios.

I don’t think homenet has any special requirements with regards to ECMP. I 
think it has been assumed that will work like in any other network. I certainly 
expect the homenet to support ECMP.
(parallel wireless links may be a bad example though, as they are probably 
quite unlikely to be equal.)

the main items of discussion in a homenet context is load balancing across 
multiple providers. in the IPv6 multi-prefix multi-homing architecture load 
balancing is done by the hosts, not by the network.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

> Your document describes (in my opinion) desireable behaviour for devices 
> going forward. I would like to see text for DHCPv6 as well, both IA_NA and 
> IA_PD, if the same kind of behaviour can work there somehow. This is out of 
> scope for homenet though.

the rule applies regardless of how the addresses have been assigned.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Ole Troan]

Fred,

Add another LAN interface to Alice, connecting host Porky.
If Alice didn’t advertise both ISP-Alice and ISP-Bob prefixes, Porky couldn’t 
use ISP Bob.
It would be a quite complicated set of rules determining when Alice should or 
should not include ISP Bob’s prefixes on a given link. I’m quite uncomfortable 
tying Router Advertisement PIO’s to routing and topology changes.

I think Brian makes a good point on slide 9:
https://www.ietf.org/proceedings/93/slides/slides-93-6man-6.pdf


  +---++———+
  |   ||  |
  |ISP-Alice  ||ISP-Bob   |
  |   ||  |
  |   ||  |
  +--+++-++
 |   |
  +--+--+  +-+-+
  |Alice|  |Bob|
  +--+--+  +-+-+
 |   |
  ++-+--+++
   ||
+--+---+ +--+—+
|Spanky| |Carol|
+--+ +--+———+
|
  +++——+
   |
+--+——+
|Alfalfa|
+———+


cheers,
Ole




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Redirect and source-specific routing

[Ole Troan]

Juliusz,

> I'm wondering if there isn't some interaction between Redirect messages and 
> source-specific routing that we're overlooking.  RFC 4861 Section 8.3 says 
> the following:
> 
>   Redirect messages apply to all flows that are being sent to a given
>   destination.  That is, upon receipt of a Redirect for a Destination
>   Address, all Destination Cache entries to that address should be
>   updated to use the specified next-hop, regardless of the contents of
>   the Flow Label field that appears in the Redirected Header option.
> 
> It does not speak of the source address, so I assume that this applies to all 
> sources.  Consider the following topology:
> 
>    A ---+--- B 
> |
> H
> 
> If A and B advertise non-overlapping source-specific default routes and H is 
> multiplexing its traffic over source addresses in both source prefixes (say, 
> it's using MP-TCP), its Destination Cache entry will flap between A and B.
> 
> If I'm right, that argues in favour of an update to RFC 4861.

you are right. these issues are currently being discussed in 6man.
see http://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-07

we haven’t reached a conclusion if a source aware redirect is needed or not (if 
that’s what you had in mind). by the way, there is also ICMP unreachable code 5 
(Source address failed ingress/egress policy), which I would think the router 
should send, rather than the redirect in this case.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] IntDir review: draft-ietf-homenet-dhcp-07

[Ole Troan]

I have been selected as the Internet Directorate reviewer for this
draft. The purpose of the review is to provide assistance to the
Internet ADs.

Although these comments are primarily for the use of the Internet ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-homenet-dncp-07.txt
Reviewer: Ole Troan
Review Date: July 7 16, 2015

The document now reads much better. I do get the impression that the text is
reverse engineered from code in a few places though.

Given that it is an "Abstract protocol" specification, that must be
combined with a profile specification to be a fully implementable, it
is somewhat difficult to predict if the specification is complete or
not. Juliusz Chroboczek is writing an independent implementation, and
I'd recommend incorporating the very informative replies the authors have made 
to his
comments on the homenet list into the document.

General comments:
=
=> Replace no affiliation with "Independent". If that's the case.

=> It is unclear to me how multiple instances of DNCP is run on a
   link. Is that something that must be specified in the profile
   document, and each profile must support multiple instances?
   Given draft-stenberg-shsp, and the way it "hijacks" the HNCP
   profile, it appears that more formal multiple instance support
   would be needed.

=> I can't help being left with the impression that fragmentation
   (section 6.3) is underspecified. Can fragmentation be left out of
   the protocol for now (and profiles requiring large TLVs can require
   a transport layer supporting segmentation and reassembly?)

=> I do find the text on transport modes somewhat confusing, U, M+U
and MulticastListen+U. I'd like to see more descriptive text

Abstract:
=

OLD:
   This document describes the Distributed Node Consensus Protocol
   (DNCP), a generic state synchronization protocol which uses Trickle
   and Merkle trees.  DNCP leaves some details unspecified or provides
   alternative options.  Therefore, only profiles which specify those
   missing parts define actual implementable DNCP-based protocols.

NEW:
   This document describes the Distributed Node Consensus Protocol
   (DNCP), a generic state synchronization protocol that uses Trickle
   and Merkle trees. DNCP is an abstract protocol, that must be
   combined with a specific profile to make a complete implementable
   protocol.

=> The purpose of that change would be to make it clear what this
is. A framework? A component that protocols can be built out of?

=> Add a reference to Merkle trees?

Section 4.2:


=> This is confusing:
o If using a stream transport, the TLV MUST be sent at least once,
  and it SHOULD be sent only once.

OLD:
*  If only unreliable unicast transport is employed, Trickle state
   is kept per each peer and it is used to send Network State TLVs
   every now and then, as specified in Section 4.3.

NEW:
*  If only unreliable unicast transport is used, Trickle state
   is kept per peer and it is used to send Network State TLVs
   intermittently, as specified in Section 4.3.

s/every now and then/now and then/

s/employed/used/

Section 4.3:

=> reference to rfc6206?


   o  the endpoint is in Multicast+Unicast transport mode, in which case
  the TLV MUST be sent over multicast.

   o  the endpoint is NOT in Multicast+Unicast transport mode, and the
  unicast transport is unreliable, in which case the TLV MUST be
  sent over unicast.

=> What do an implementation do if the endpoint is not in M+U
transport mode, and the unicast transport is reliable?

(I do find the transport modes confusing, and I'm not sure I
understand the MulticastListen mode).

s/when using also secure unicast/when using secure unicast/

Section 4.4:

=> What is meant by: "link with shared bandwidth"?


  o  Any other TLV: TLVs not recognized by the receiver MUST be
  silently ignored.

=> doesn't that mean it isn't stored in the Merkle tree? and the
hashes don't compute?

Section 4.6:

=> First mention of a topology graph.

Section 5:
==

o  Endpoint identifier: the 32-bit opaque value uniquely identifying
  it within the local node.

=> "it"? I think I'm still confused what is an endpoint, what is a
peer and what is a node.

o  Range of addresses: the DNCP nodes that are allowed to connect.

=> How does a range of addresses look like and how is it used?
   I find only one occurence in the document.

Section 6.1:

   A DNCP profile MAY specify either per-endpoint or per-peer keep-alive
   support.

=> Again I'm confused over the usage of endpoint versus peer.
What's the difference between per-peer 

Re: [homenet] 6renum redux [Routing protocol comparison document]

[Ole Troan]

Brian,

>>> Much as I love MPTCP, it only helps TCP sessions. And it requires both
>>> hosts to
>>> be updated to be effective.
>> 
>> IPv6 multi-prefix multi-homing requires both hosts to support it. which 
>> means transport fixes.
> 
> Or fully operational shim6, which was conceived and designed for this
> exact problem.

right. I tend to think that the problems of multi-homing, multi-endpoint, 
mobility, and renumbering are tightly coupled.
you might need to expose some of this to the transport and applications. I have 
more hope of solving this at L4.5 or even L5 (I suppose talking about a 
“session layer” would get me banned from the IETF. ;-)), than at L3.5.

to take the digression back to homenet; if we agree this is a problem for 
transport or above, then at least we can declare victory by claiming it isn’t 
our problem.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] 6renum redux [Routing protocol comparison document]

[Ole Troan]

>> Much as I love MPTCP, it only helps TCP sessions. And it requires both
>> hosts to
>> be updated to be effective.
> 
> IPv6 multi-prefix multi-homing requires both hosts to support it. which means 
> transport fixes.

to reply to myself. is anyone aware of any document describing the 
"expectations for hosts / host gaps" with regards to IPv6 multi-prefix 
multi-homing? including renumbering, mobility, redundancy, load sharing... 
essentially the RFC3582 goals.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] 6renum redux [Routing protocol comparison document]

[Ole Troan]

> Much as I love MPTCP, it only helps TCP sessions. And it requires both
> hosts to
> be updated to be effective.

IPv6 multi-prefix multi-homing requires both hosts to support it. which means 
transport fixes.

cheers,
Ole



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] MPVD requirments in homenet

[Ole Troan]

Liang,

what do you mean by "multiple services"?
if you mean walled garden, the homenet architecture only has the following to 
say:

   "It should be noted that some multihoming scenarios may see one
   upstream being a "walled garden" and thus only appropriate for
   connectivity to the services of that provider; an example may be a
   VPN service that only routes back to the enterprise business network
   of a user in the homenet.  As per Section 4.2.1 of [RFC3002], we do
   not specifically target walled-garden multihoming as a goal of this
   document."

cheers,
Ole


> On 03 Mar 2015, at 10:30 , Liang Geng  wrote:
> 
> Hi all,
> 
> I'm Liang from China Mobile, a recent follower of this community.
> 
> Following a previous thread concerning the discussion of MPVD in Homenet on
> 3rd Feb, I personally think that certain use cases are quite well in line
> with the mif MPVD scenario.
> 
> As homenet architecture provides autonomic network configuration in future
> multi-service, multi-homed environment, I think it is also a new challenge
> in terms of CPE management. My immature thought would be that MPvD may
> provide a promising model. May I propose the following problems for the list
> to see if it is worthy of some serious investigation, on which hopefully
> would be something interesting I could make a brief draft for further
> discussion (maybe in Dallas meeting)?
> 
> Problems to be addressed
> 1. Use case of MPVD in homenet
>   -Single ISP, multiple services (covers single/multiple CE router(s))
>   -Multiple ISP, multiple services (covers single/multiple CE
> router(s))
> 2. The association of PvD and network configuration in homenet
>   -Address configuration
>   -Naming and service discovery
>   For both, now thinking of a new PvD TLV which enables the
> association of certain configuration and PvD. Initial thought would be that
> no DHCP option extension is needed terms of HNCP based pvd coveying. Host
> and non-HNCP routers may refer to mif work on how pvd information is
> provided.
> ...more to be discussed and added
> 
> Any comments would be extremely welcome.
> 
> Best wishes
> Liang
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00

[Ole Troan]

> Following question may strictly speaking be out of scope for Homenet, as it 
> is about the WAN side interface and interaction with the upstream ISP router.
> 
> Whilst setting up my own HNCP testbed, I was attempting to configure my own 
> "last-hop ISP router" assuming a customer-owned Homenet router connected to 
> my last-hop ISP router via Ethernet.
> [also so I could do weird things/perform tests/interrupt/monitor DHCP PD]
> 
> Was there any further work done on 
> draft-stenberg-v6ops-pd-route-maintenance-00?
> 
> Or is the Best Current Practice for non-point-to-point links still described 
> in draft-stenberg-v6ops-pd-route-maintenance-00?
> 
> I was planning on using ISC DHCP 4.3.1 together with an external script as 
> described in https://github.com/mpalmer/isc-dhcp contrib, to detect the next 
> hop address of my homenet router and install the relevant route for the 
> delegated prefix on the last-hop ISP router (a Linux box).

typically the ISP router snoops DHCPv6 messages and does route injection based 
on that, or the DHCPv6 server runs on the ISP router and does route injection 
based on binding state.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Roaming hosts [was: Routing protocol comparison document]

[Ole Troan]

>>> On 21 Feb 2015, at 16:06 , Juliusz Chroboczek 
>>>  wrote:
>>> 
> The client is running a stub implementation of the routing protocol.
>>> 
 I thought we already had decided we didn't require changes to the host?
>>> 
>>> We don't *require* changes to the host.  We propose optional host
>>> modifications that improve the user experience.
>> 
>> exactly.
>> you aren't going to have much fun with multi-prefix multi-homing without 
>> host changes anyhow.
> 
> Let me get this straight: So the proposal is that end systems will have to 
> change their IPv6 address when it moves between wifi APs if it's a current 
> end system, and in order to keep its address, it needs to start to speak HNCP?

are you replying to the point I made? cause fully functioning MHMP requires 
host support (read MP-TCP/session layer) regardless of moving or not.

with regards to a proposal I haven't seen one written up, but I don't think 
what your are stating is it. ;-)

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Roaming hosts [was: Routing protocol comparison document]

[Ole Troan]

> On 21 Feb 2015, at 16:06 , Juliusz Chroboczek 
>  wrote:
> 
>>> The client is running a stub implementation of the routing protocol.
> 
>> I thought we already had decided we didn't require changes to the host?
> 
> We don't *require* changes to the host.  We propose optional host
> modifications that improve the user experience.

exactly.
you aren't going to have much fun with multi-prefix multi-homing without host 
changes anyhow.

> The chairs will correct me if I'm wrong, but I believe this is consistent
> with Homenet's charter.

cheers,
Ole




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing protocol comparison document

[Ole Troan]

Mikael,

>> Back to the subject: What are the requirements of a high performance WiFi 
>> home network to the homenet routing protocol? I guess we don't know.
> 
> Within the current framework to solve this problem with what exists today 
> when it comes to clients, I would say we need either:
> 
> 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the 
> APs using the same SSID, so the SSID can have the same L2 domain. This would 
> probably mean we want to increase MTU on the physical links to avoid 
> fragmentation. Messy. Possibly we could advertise lower MTU on the wifi 
> network to minimize fragmentation if we don't raise MTU.
> 
> 2. We set up some kind of L2 switching domain between the APs. This would 
> require VLAN support in the HGWs, and something to set this up with loop 
> avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as 
> control plane, that way we could possibly run the same IGP for both L2 and 
> L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds 
> like an understatement.
> 
> Frankly, I don't know how to solve this without a lot of complication.

why do you think this has to be solved at L2?

> We need clients to be able to change IPv6 addresses without losing existing 
> connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two 
> connections at once and inform the application that one address is going away 
> soon so it can do its thing to try to handle this?

at least you can do:
L3 - route injection (got a routing protocol there already, use it)
L3.5 - SHIM6. not deployable
L4/L5 - MP-TCP
L5/L7  - MOSH

cheers,
Ole



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing protocol comparison document

[Ole Troan]

>> 
 It means that every single device on a wired network is on a different 
 subnet.  Perhaps it doesn't cause any extreme harm, but it certainly makes 
 managing and debugging the network harder, and it means that you can't 
 have a layer two switch anymore.  So the question I would ask is not "is 
 there a problem with this," because obviously there is, but rather "is 
 there a benefit to doing it this way."  I am curious to know what you 
 think the benefit is.
>>> 
>>> I am not mandating that each and every device is in its own broadcast 
>>> domain, I am however advocating that we leave the model that has been 
>>> prevalent for 10-15 years at least, ie that a home gateway has a "WAN" port 
>>> and 4 "LAN" ports, and these 4 ports are bridged. I'm saying the typical 
>>> device should have 4-5 "L3" ports. You're then free to connect one of these 
>>> to your L2 switch if you so please.
>>> 
>>> I would like my router-to-router links to not have a lot of hosts in them 
>>> if I can avoid it.
>> 
>> +1.
>> 
>> there are very few shared media around anymore.
> 
> Still one to phase out: spectrum ;-)
> 
> I would say the opposite, I see kids that have never been connected to a 
> wired link. What about wireless repeaters, which forward packets and do not 
> have a network jacket? Wireless backhaul links to ISP?

yes, at L1 but not L2, which was what I was trying to say. citing 802.11 as an 
example.

cheers,
Ole


> 
> Teco
> 
> 
>> I don't think I've ever been connected to a 10base5.
>> why should the IP subnet model emulate a shared medium, when the physical 
>> topology is a star.
>> 
>> wireless with security is also a star topology, with a unidirectional 
>> broadcast channel.
>> 
>> cheers,
>> Ole
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing protocol comparison document

[Ole Troan]

>> It means that every single device on a wired network is on a different 
>> subnet.  Perhaps it doesn't cause any extreme harm, but it certainly makes 
>> managing and debugging the network harder, and it means that you can't have 
>> a layer two switch anymore.  So the question I would ask is not "is there a 
>> problem with this," because obviously there is, but rather "is there a 
>> benefit to doing it this way."  I am curious to know what you think the 
>> benefit is.
> 
> I am not mandating that each and every device is in its own broadcast domain, 
> I am however advocating that we leave the model that has been prevalent for 
> 10-15 years at least, ie that a home gateway has a "WAN" port and 4 "LAN" 
> ports, and these 4 ports are bridged. I'm saying the typical device should 
> have 4-5 "L3" ports. You're then free to connect one of these to your L2 
> switch if you so please.
> 
> I would like my router-to-router links to not have a lot of hosts in them if 
> I can avoid it.

+1.

there are very few shared media around anymore. I don't think I've ever been 
connected to a 10base5.
why should the IP subnet model emulate a shared medium, when the physical 
topology is a star.

wireless with security is also a star topology, with a unidirectional broadcast 
channel.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenets and MPVD

[Ole Troan]

>> PVD tell you also about the kind of connectivity available there etc. While 
>> I am sure we _could_ fabricate local one, it is much easier to tell that 
>> e.g. one upstream connection is pay-per-byte 4g, and other one is VDSL2 and 
>> let hosts make educated choices instead of guesses about source prefixes to 
>> use.
> 
> One of the design goals of the PVD architecture is to make it possible to get 
> the same behavior in a 4G handset with a Wifi interface and in a laptop with 
> no 4G interface that's connected to a network with a 4G PVD and a wireline 
> PVD.

what behaviour is that?

>> Is this covered somewhere elsewhere in the DHCP option jungle?
> 
> A document is being worked on to address this, but no, it is not yet covered.
> 

cheers,
Ole

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

Re: [homenet] Homenets and MPVD

[Ole Troan]

Markus,

>> All routers gather this information through HNCP and use it to configure 
>> hosts. DHCP options that are associated with a given delegated prefix are 
>> given to hosts associated with the link prefix provided by the prefix 
>> assignment algorithm. DHCP options that are not associated with a delegated 
>> prefix are aggregated and given to the host (Excepted for the DNS server 
>> option, as the router is used as DNS relay).
> 
> DNS server option is mostly changed so we can do in-home service discovery. 
> In MIF world, we would probably pass along DNS servers within PVDs as is, 
> provide (e.g.) ‘.home’ PVD for in-home services only, and provide only to 
> legacy clients the ‘relay’ DNS server address. So oddly enough, current 
> scheme would work, most likely as-is ;) The unknown new PVD option would be 
> passed along as is, and the clients would treat the provided legacy DNS 
> server (+search path) as an extra implicit PVD with hopefully lower priority 
> than the explicit PVDs.
> 
> Not changing PVDs may be crucial if the PVD authentication ever takes hold, 
> as changing it’s content then may make it altogether invalid from the 
> client’s point of view. 

is it actually obvious that you'd pass the PVDs to the hosts in homenets?
PVDs contain policy. and allowing them to pass the administrative boundary into 
a home is also up to policy.
given that we already have options to control DNS server selection policy. why 
can't the home border amalgamate that information (according to local policy)?

sorry, I'm struggling to understand the PVD use case I suppose.

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

Re: [homenet] Next Steps for Routing Protocol

[Ole Troan]

Michael,

>> 1) pure peering - homenet -> LLN ::/0 
>>   - LLN -> homenet more specifics
>> for LLN routes and cloud service prefixes
> 
> I don't understand your ::/0 here.
> I think the LLN gets a ::/0 route into the homenet, and the homenet gets a
> specific route into the LLN.  Is this what you were trying to say?

homenet advertises a default into LLN.
or LLN discovers a default from homenet.

LLN advertises more specifics into homenet.

> 
>> for the pure peering case, I think it would be sufficient for the LLN
>> to do router discovery (as a host) and for the homenet to provide some
>> mechanism for the LLN to register which routes it should advertise for
>> it (aka buddy routing). that mechanism "please inject these routes for
>> me", would most likely not require participation in a routing protocol,
>> nor have stringent requirements for convergence, dead neighbour
>> detection. we may possibly think of them more as static routes.
> 
> Right, I think we should have this... I also think it simplifies how things
> like virtual machine systems might work; HNCP gets them a prefix, and they
> are always a stub network too.

the LLN may not get a prefix from the homenet. that depends. the LLN may make 
up its own from ULA, or it may get one from LLN cloud provider. the LLN could 
even number the homenet.

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

Re: [homenet] Next Steps for Routing Protocol

[Ole Troan]

Juliusz,

you could also inject the route with a 3rd party next-hop pointing to L.

cheers,
Ole


> On 16 Nov 2014, at 10:54 , Juliusz Chroboczek 
>  wrote:
> 
>>> If the latter, I can see some opportunities for transient routing loops
>>> if not done carefully.  (And you certainly don't want a routing loop on
>>> a link with low-power nodes.)
> 
>> That’s interesting. Could you try explaining what could happen ?
> 
> I hope I'm just being paranoid, since I rather like the idea of
> redistribution through HNCP.
> 
> A and B are homenet nodes.  L is a low power node.
> 
>   A-B
>\   /
> \ /
>  L
>  |
>  |
> LLN
> 
> A and B are both announcing the LLN route.  L crashes.  A and B both
> notice that L is no longer reachable, so each of them attempts to route
> through the other one.  You have a transient routing loop that lasts until
> A and B agree on the fact that L is unreachable.
> 
> On a wired network, the routing loop will be extremely short-lived (one
> successful packet exchange for both Babel and OSPF, not sure about IS-IS).
> I'm not sure what will happen on a wireless network, but I've learnt to be
> pessimistic about the behaviour of 802.11.  I could imagine cases where
> the looping data traffic prevents A and B from communicating successfully,
> especially if L had more than just two Homenet neighbours.
> 
> In the case of Babel (or EIGRP, for that matter), running a stub
> implementation on L solves the problem quite nicely, by allowing the
> loop-avoidance algorithm to kick in before the loop is established.  With
> link state, you still get a transient loop, but you're relying on the
> carefully designed flooding algorithm of a mature routing protocol to
> clear it, rather than counting on the poorly understood interactions
> between the routing protocol and HNCP happening in the right order.
> 
> -- Juliusz
> 
> ___
> 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] Next Steps for HNCP

[Ole Troan]

Pierre,

>> while 2 and 3 require participation in HNCP, my worry is that even HNCP is 
>> too chatty for the LLN to deal with. do we have any numbers? presumably one 
>> could design a stub HNCP, where the peer only received messages relevant to 
>> it, possibly even with a HNCP sleep proxy.
> 
> 
> We could try to make HNCP more Low-Power-friendly, but there will always be 
> cases where HNCP will kill LP nodes because HNCP provides network-wide state 
> synchronization (e.g. a buggy node keeps sending changing updates).
> 
> IMO, the reason why the ‘buddy’ approach was relevant for Low-Capacity 
> devices like James’ is that HNCP could be useful for different things (e.g. 
> advertise a Delegated Prefix), which we can’t really do with a routing 
> protocol. So instead of having HNCP + RP, it would be HNCP alone. In which 
> case the chattyness of HNCP doesn’t matter much. 
> 
> That said, I think the chatyness of both HNCP and the RP should be taken into 
> account, as a ‘weak' requirement (i.e. it should not override already 
> existing requirements).

I think we need to separate the two discussions. let's start a separate work 
item for peering with LLNs.

> Additionally, I **don’t** think the WG should consider defining a full 
> HNCP-proxying mechanism. If HNCP is successful, and if the need appears to be 
> strong, OK. But we should make something that works without such support 
> first. Proposal #1 is, IMO, a correct trade-of.

if proposal #1 is for peering with LLNs I don't think that's correct. firstly 
we need to get the requirements better defined. and by the way overloading the 
assigned prefix TLV as a "register external route" option is pretty ugly. 
you'll then get assigned prefixes which aren't even more specifics out of the 
delegated prefix. keep the prefix assignment mechanism clean please.

cheers,
Ole

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

Re: [homenet] Next Steps for Routing Protocol

[Ole Troan]

>> While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
>> proposed that the IoT device domain would never be used for transit so it
>> only needed to get a default (or other aggregate) and inject a prefix and
>> the HNCP could be made to satisfy this requirement.
> 
> Could you please clarify what you mean by "inject" a prefix in this
> context?  Stub router sends HNCP message to non-stub router asking it to
> perform redistribution?  When does the non-stub router cease redistributing?

indeed. there are quite a few unknowns here. on the Thursday meeting I think we 
jumped too early into making assumptions on solutions before understanding the 
requirements.

from speaking to James, I can at least see the variants for homenet to LLN 
peering:

1) pure peering
- homenet -> LLN ::/0
- LLN -> homenet more specifics for LLN routes and cloud service prefixes

2) peering + homenet numbered from LLN
3) peering + LLN numbered from homenet

as soon as there is a requirement for one of the networks providing prefix 
assignment to the other, some variant of HNCP is required in addition to some 
form of peering routing relationship.

for the pure peering case, I think it would be sufficient for the LLN to do 
router discovery (as a host) and for the homenet to provide some mechanism for 
the LLN to register which routes it should advertise for it (aka buddy 
routing). that mechanism "please inject these routes for me", would most likely 
not require participation in a routing protocol, nor have stringent 
requirements for convergence, dead neighbour detection. we may possibly think 
of them more as static routes.

while 2 and 3 require participation in HNCP, my worry is that even HNCP is too 
chatty for the LLN to deal with. do we have any numbers? presumably one could 
design a stub HNCP, where the peer only received messages relevant to it, 
possibly even with a HNCP sleep proxy.

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

Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15

[Ole Troan]

Ted,

>> the "flow-through" model as far as I can recall suffers from DHCP's general 
>> problem of dealing with multiple sources of information (think multihoming 
>> with separate CE routers), in addition you either need to build what's 
>> essentially a spanning tree of DHCP relays or you need some mechanism to 
>> discover the set of DHCP server(s). certainly do-able, but not quite out of 
>> the box.
> 
> Actually it doesn't suffer from this problem.   You just wind up getting a 
> prefix delegation per edge router, and when you get a delegation, you add 
> that edge router to the list of routers to which you will relay downstream 
> prefix delegation requests.   You do not need spanning tree because if you 
> reach the same router through two different paths, you will just get the same 
> delegation twice per DUID/IAID.
> 
> The reason homenet didn't go with this solution is essentially that HNCP has 
> a better feature set and is easier to make work in a homenet environment.
> 
> (To be clear, I am just explaining the prefix delegation model.   If Anima 
> doesn't want to do it that way, that's fine with me, just as it's fine with 
> me that homenet went with HNCP.)
> 

it isn't as obvious as you make it out to be. there is no point in us arguing 
over that here (we have had this exact argument previously), write a draft if 
you think the flow-through model is viable in a network with multiple edges and 
arbitrary topology.

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

Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15

[Ole Troan]

>> What does flow-through PD mean? Do you have any reference on that?
> 
> It means that the edge router has the delegation, and then sub-delegates 
> individual /64s from the pool of /64s it was delegated by the ISP, rather 
> than splitting its delegation and delegating chunks of that delegation to 
> downstream routers which will then delegate in turn.   In order for this to 
> work, downstream routers have to relay PD requests to the edge router, and 
> install routes to the delegated prefixes.   Something analogous could work on 
> an autonomous network; I don't know that it's the right way to solve the 
> problem, but it's certainly one way to solve the problem.   Homenet went with 
> HNCP because it's more sensitive to arbitrary topology changes.
> 
> The hierarchical model doesn't work because it doesn't anticipate new routers 
> being added to the network, and doesn't account for unbalanced topologies.   
> I thought the hipnet proposal wound up going with the flow-through model, not 
> the hierarchical model, but I may be mistaken.

I think the homenet wg did a good of analysing the 3 variants proposed.
the "flow-through" model as far as I can recall suffers from DHCP's general 
problem of dealing with multiple sources of information (think multihoming with 
separate CE routers), in addition you either need to build what's essentially a 
spanning tree of DHCP relays or you need some mechanism to discover the set of 
DHCP server(s). certainly do-able, but not quite out of the box.

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

Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Ole Troan]

David,

> ::/0 from 2001:db8:1::/48 via PA-provider-1
> ::/0 from 2001:db8:2::/48 via PA-provider-2
> ::/0 from 2001:db8:::/48 unreachable
> 2001:db8:::/48 from 2001:db8:::/48 via IPsec-gateway
> 2001:db8:::/48 from ::/0 unreachable
> 
> Where the last route would prevent accidental leaking of packets onto
> the internet in case the IPsec gateway malfunctions.  (The 3rd route is
> redundant if there's no "::/0 from ::/0")
> 
> But - apart from ease of use for multiple prefixes, this can be done
> without SADR just fine, the only advantage is that there's full
> information regarding which source addresses work with which
> destinations.  If we get that to hosts, and into their source address
> selection, then we won something.

in a simple triangle topology:

   ||
CE1  CE2
  \ /
   \   /
   IR1
 |
-
   |
 Host

with PA1 and PA2 doing BCP38 filtering and a non SADR capable network, I would 
assert that you cannot do this without SADR.
IR1 load balances, and you could end up in a situation where IR1 load balancing 
would pick CE1 exit for PA2 source address, and CE2 exit for PA1 source 
address. with the result that whatever the host tried to do, all traffic would 
be black-holed by the ISP ingress filters.

with regards to getting SAS policies into hosts, that isn't necessary for the 
multi-homed to congruent networks case. it is needed in the walled garden cases 
(but there are some many other issues with walled gardens that I'm not sure the 
IETF should try to fix a broken business model). we do have a DHCP option 
already to configure a host's SAS table for this purpose. RFC7078.

cheers,
Ole

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

Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Ole Troan]

Fred,

>>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-qualifiers/?include_text=1
>>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?include_text=1
> 
> Speaking strictly for myself, I’m not sure why homenet is relevant. The 
> technology is related to networks that have different routing depend on on 
> one’s use case. A class of solutions for it has been called the “fish” 
> problem, and built using multi-topology routing. In homenet, it’s called 
> SADR, and is primarily about egress routing (routing to an egress to an 
> upstream ISP that gave you a PA prefix). While one doesn’t really want to 
> confuse theory with practice, in theory it could be used between points of a 
> network, to prevent folks using one set of prefixes to talk with another set, 
> or to force routing of some sessions in some ways.
> 
> Personally, those are a class of problems I associate with campus networks 
> more than residential networks.

why homenet is relevant?
isn't multi-prefix multi-homing one of the most obvious use cases for source 
address dependent routing? that's not restricted with homenets, but also any 
small network. I'm assuming large networks will continue with PI addresses and 
BGP based multihoming.

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

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

[Ole Troan]

Pierre,

I certainly understand your argument, and we don't disagree on the technical 
merit.

> I’m proposing this change then.
> 
> 1. In case the provided prefix is 64, the default consist in assigning 
> prefixes of length 64 first.
> 2. I’m adding a reference to 6man-why64.
> 
> When the algorithm decides to make a new assignment, it first needs
>to specify the desired size of the assigned prefix.  Although this
>algorithm intends to remain generic, it was observed in
>[I-D.ietf-6man-why64] that hosts may malfunction when the prefix
>length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.
>The following table MAY be used as default values, where X is the
>length of the delegated prefix.
> 
>If X <= 64:  Prefix length = 64

the "may malfunction" is not the reason for why the IPv6 address is classful, 
so please don't put that as justification for a default of 64.

I would like this document to say as little as possible about the boundary.
RFC6204 says:
L-2:   The IPv6 CE router MUST assign a separate /64 from its
  delegated prefix(es) (and ULA prefix if configured to provide
  ULA addressing) for each of its LAN interfaces.

which you could tweak to fit this document as well. have text like that in one 
place, and then all other places threat it as an arbitrary length.

please remove the table with the description of what to do for various values 
of X.
I'd be happy with a statement like in RFC6204:
   WPD-3:  ...If the
   delegated prefix is too small to address all of its
   interfaces, the IPv6 CE router SHOULD log a system management
   error.

> Processes proposed in the appendix are optional.
> Our implementation supports some part of it, and it works fine in our 
> test-cases.
> I’d rather have a /80 than no connectivity at all (And it just works.).
> IMO, why64 is way too pessimistic on the current implementation state and 
> even more when it comes to the progress implementations will do in the coming 
> years.
> 
> And we either do that or let people do NAT66. ;)
> 
> 
> Is it OK for you Ole ?

I'd also remove the appendix.
it doesn't make sense to specify something that breaks SLAAC.

protocol design is politics. we want to make it clear to the address delegation 
authorities that not delegating a large enough address block will lead to 
breakage.

in my view, if we let this principle slide, then the risk isn't that the 
delegations are /80s, but that they will be /128s. and you're back to IPv6 NAT 
anyhow.

cheers,
Ole

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

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

[Ole Troan]

Pierre, Alex,

please make sure this document does comply with 
http://datatracker.ietf.org/doc/draft-ietf-6man-why64/
while I think the algorithm and data formats should support any prefix lengths, 
I don't think the sections dealing with "what if we've run out of prefixes" 
should be included in this document.

cheers,
Ole


> On 08 Oct 2014, at 13:28 , Pierre Pfister  wrote:
> 
> Hi Alex,
> 
> Reply is inlined,
> 
> Le 8 oct. 2014 à 12:09, Alexandru Petrescu  a 
> écrit :
> 
>> Hi Pierre,
>> 
>> Thanks for the draft update.  Now I have two questions:
>> 
>>> prefixes of size 64 are RECOMMENDED.
>> 
>> Why is this length recommended?  I think it may be because of Ethernet?
> 
> I’m not a big fan of putting 64s everywhere neither. And I strongly disagree 
> with mandating 64 bit long prefixes. 
> The prefix algorithm itself is agnostic on this side.
> 
> Nevertheless, some parts of this document are home-network specific. 
> Not even talking about crappy implementations, home network links should 
> support SLAAC whenever possible.
> Which is the reason why using 64bit long prefixes is RECOMMENDED.
> 
> But smaller prefixes are better than *no prefix at all*. 
> When there are not enough prefixes available (e.g. the ISP provides a single 
> 64 while we have multiple links), smaller prefixes can be used (80 for 
> instance). 
> Which means dhcpv6 must be used.
> Our implementation supports it, and it works with my laptop.
> 
> But again, that should be avoided whenever possible. And ISPs MUST provided 
> enough prefixes (IMO).
> 
>> 
>> Maybe it would be advantageous to not make any recommendation on the prefix 
>> length.  Some times this may develop into a barrier beyond which it will be 
>> hard to go.
>> 
>> The other question is about the assumed capability to decide non between 
>> prefixes, such as to detect collisions.  Do you think it is possible to 
>> decide equality between prefixes?  I rather think prefixes have a more 
>> refined relationship than just equal/not-equal - e.g. they are also 
>> aggregated.
>> 
>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do you think 
>> a 'collision' could be detected?  I doubt we have such an algorithm 
>> somewhere.
>> 
> 
> Equality is never considered alone. Actually, most of the time, you will find 
> considerations such as:
> The prefix is not included or does not include any other Assigned
>   Prefix with a higher precedence.
> 
> This is how collisions are detected.
> 
> Cheers,
> 
> - Pierre
> 
> 
>> Alex
>> 
>> 
>> 
>> Le 30/06/2014 17:18, Pierre Pfister a écrit :
>>> Hello group,
>>> 
>>> I’d like to inform you about the changes made in the two last 
>>> homenet-prefix-assignment updates.
>>> 
>>> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>>> 
>>> The changes are mostly about fixing typos, but a few technical changes have 
>>> been made as well (based on the experience gained from the implementation 
>>> of the Prefix Assignment Algorithm over HNCP).
>>> 
>>> 
>>> — Changes between 00 and 01
>>> 
>>> - If a Delegated Prefix is included in another Delegated Prefix, it is 
>>> ignored. This is intended to improve support for non-homenet routers that 
>>> provide prefix sub-delegation. That way, sub-delegated prefixes are ignored.
>>> 
>>> - Adding network leader definition (The router with the highest identifier).
>>> 
>>> - Add a section about DHCPv6 downstream prefix delegation. For downstream 
>>> RFC7084 routers support.
>>> 
>>> - Adding Delegated Prefix deprecation procedure in order to differentiate 
>>> prefix deprecation and node disconnection. When a node disconnect, the DPs 
>>> advertised by this node may be kept some time (depending on the DP's 
>>> lifetimes). But if a DP is actively deprecated, nodes must stop using it 
>>> immediately.
>>> 
>>> 
>>> — Changes between 01 and 02
>>> 
>>> - Designated router election can make use of the information provided by 
>>> the flooding protocol (i.e. when no router is designated yet, only the 
>>> highest router id present on the link can become designated).
>>> 
>>> - New implementation guideline in appendix concerning "prefix waste 
>>> avoidance". It proposes an algorithm that provides a good trade-of between 
>>> randomness, pseudo-randomness and prefix selection efficiency.
>>> 
>>> 
>>> 
>>> Comments are welcome,
>>> 
>>> Pierre Pfister
>>> ___
>>> 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

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

Re: [homenet] Clarification on Routing Thoughts

[Ole Troan]

>>> It seems to me that you are grasping for a use case to justify a split
>>> where none is needed.  Protocols like OSPF, IS-IS and Babel would all
>>> work in both environments. RIP won't.  So this seems more like an
>>> argument not to use RIP than an argument to have two different homenet
>>> router profiles.
>> 
>> For the record, can you expound on the technical reason why RIP(v2) won't
>> work?  (I'm not a fan of it, but last time I used it was on SunOS 3 or
>> something)
> 
> hop count isn't a great tool for expressing that  your gig-e port is a
> more desireable path if up  then the wifi interface.
> 

the cost/metric is perfectly fine for that.
assuming a relatively small network diameter.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] WG adoption of draft-stenberg-homenet-hncp-00

[Ole Troan]

> At IETF 89 in London we took three hums:
> 
> 1. On use of OSPF vs HNCP for configuration - strong consensus for HNCP
> 
> 2. On how many routing protocols we should support in Homenet -
>  strong consensus that it should be zero or one, but no consensus yet
>  on which.
> 
> 3. On adoption of HNCP as a WG item - good consensus for, a few undecided,
>  none against.
> 
> On this basis the Chairs wish to proceed with the formal call for adoption of 
> draft-stenberg-homenet-hncp-00, with a two week response window.
> 

I'm in favour of adopting this document, with the premise that HNCP is not 
going to be yet another routing protocol.
that is restricted to bootstrapping / configuring the home network.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

[Ole Troan]

Ted,

>> you make it sound like that's a part and parcel of DHCP. I can't see how you 
>> can implement that today.
> 
> Eh?   It's dead trivial.   The draft already sets up relay agents—the only 
> difference is that all relays now relay to both CERs, not just one.   The 
> requesting routers get delegations from both CERs and use both delegations.

you cut out my question about how to build the relay topology.
e.g. relays would have to replicate client messages to multiple CERs.

> You are right that no existing implementation does this, but no existing 
> implementation does homenet, so that seems like a pretty mild criticism!   :)

a goal for homenet is to reuse existing implementations.

>> "homenet routing protocol server"? this proposal makes do with static 
>> routing.
> 
> When I said the proposal looked mostly right, I was referring to the DHCP PD 
> aspect, not the static routing aspect.   Static routing might work, but I 
> suspect it would be brittle.
> 
>> how do you deal with multiple routers on the link? just keep adding /64s out 
>> of the same site-prefix to it?
> 
> Only the CERs delegate prefixes.  If you have multiple paths to the same CER, 
> you will still only get one prefix per identity association.

a link with multiple routers on it will get multiple prefixes from the same 
site prefix.

>> how does the network react to network events? given you rely on DHCP 
>> snooping then network convergence time
>> is rather glacial.
> 
> Right, I'm not arguing that we don't need a routing protocol.   I'm not even 
> particularly arguing that PD is the right way to delegate prefixes.   But it 
> would work, and with no protocol changes—it would just require an operations 
> document to explain how to do it.

I see you are making that assertion. I don't believe you.
please write a draft how this would work.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

[Ole Troan]

Ted,

>> please take a look at those drafts, and let us know what we've missed in the 
>> DHCP PD "solution space".
> 
> I've read all those drafts at one time or another.   I just checked the 
> latest version of 
> http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and it appears 
> to do pretty much the right thing.
> 
> One thing that isn't mentioned in that draft that I don't think is intuitive 
> to all readers is that if you have two CERs, this technique still works; the 
> only difference is that the technique has to be done independently by each 
> internal router with respect to each CER.

you make it sound like that's a part and parcel of DHCP. I can't see how you 
can implement that today.
are there any implementations doing this? I have never seen any.
as an example of the problems you'll encounter. how does the RR detect the 
difference between a backup DR and a separate DR? first case it should pick the 
best server, second case it should set up sessions to both.

> This draft also does not appear to talk about how to get rid of prefixes to 
> CERs that have failed.   Ideally the homenet routing protocol server could 
> signal the DHCPv6 PD requesting router server when a CER has gone away, or 
> else the PD requesting router server could poll for that information from 
> time to time (you want a little hysteresis to avoid needlessly dropping 
> prefixes in the event of a router reboot, of course).

"homenet routing protocol server"? this proposal makes do with static routing.

given an arbitrary topology.
how do you build the relay topology and discover DHCP servers?
   use site-local multicast -> we don’t quite know how to bootstrap that?
   hop-by-hop relaying? how do you deal with loops?
   you're essentially building a spanning tree of relays.
how do you deal with multiple routers on the link? just keep adding /64s out of 
the same site-prefix to it?

how does the network react to network events? given you rely on DHCP snooping 
then network convergence time
is rather glacial.

while DHCP PD may look like a candidate at first glance, to make it work in all 
corner cases, you essentially build something quite different than current 
DHCP. then you might as well use a real routing protocol and a prefix 
assignment protocol designed for the purpose.

cheers,
Ole



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

[Ole Troan]

Ted,

>> actually, we're talking about prefix assignment. which may be splitting 
>> hairs, but isn't quite the same as prefix delegation.
> 
> Splain?   You mean we're talking about the general problem, rather than the 
> DHCP-PD solution?   If so, that's fine, but the specific comment that Markus 
> made was about DHCP PD, and that's what I was responding to.   I am not 
> specifically advocating the use of DHCP PD to solve this problem, but I do 
> want to see it evaluated realistically, and not on the basis of a 
> misunderstanding of what it does and how it's used.

as one of the authors of RFC3633, DHCP PD was not designed to do assignment of 
prefixes inside a network.
DHCP PD was designed to be a "fax replacement".

there has been a number of proposals for how DHCP PD could be adapted for this 
purpose:

they generally fall into one of flat assignment with central DHCP server or 
hierarchical PD with a spanning tree of DHCP relays.

http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01
http://tools.ietf.org/html/draft-chakrabarti-homenet-prefix-alloc-01
http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf-01
http://tools.ietf.org/html/draft-grundemann-hipnet-00

please take a look at those drafts, and let us know what we've missed in the 
DHCP PD "solution space".

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

[Ole Troan]

Ted,

>> I thought you were asking for host changes to support multiple servers (even 
>> if RFC says they should, and I’m not sure it does, I have yet to find one 
>> that does).
> 
> I think host changes to make this work will be crucial to having hosts that 
> can operate on multiple prefixes managed by different organizations on the 
> same wire, but I don't think that homenet clients need this, because most 
> likely they'll be doing SLAAC, and maybe getting some local configuration 
> parameters with stateless DHCP, which themselves would have to be derived 
> automatically by the homenet, either through internal communication or from 
> externally-received information.

yes, and with the "derived automatically" mechanism you could also use DHCP for 
address assignment.
the homenet side of the routers "managed by different organisations" would of 
course have to be managed (or non-managed) by the homenet itself.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DHCP PD

[Ole Troan]

>> Given N*10^8+ (conservative estimate, N some single digit probably) 
>> potential homenet hosts already out there and 0 homenet routers, designing 
>> with the assumption that ‘yeah, hosts can change’ doesn’t sound too 
>> reasonable to me.
>> 
>> Then again, what’s wrong with fighting windmills?
> 
> We're talking about prefix delegation.   Prefix delegation runs on routers, 
> not hosts.

actually, we're talking about prefix assignment. which may be splitting hairs, 
but isn't quite the same as prefix delegation.

cheers,
Ole



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

> 7) I generally despair of this entire debate, and wish more people
> were writing code, doing experiments, and working inside the real
> world. I hate that this discussion has ratholed on the method of
> distribution, rather on than on "what configuration information needs
> to be propagated inside the home on zigbee, wifi, lte, moca, homeplug,
> in order to have grandma be able to get her pr0n and meds from her
> high-tech wheelchair. "

apart from the sentence making it appear that "configuration information" 
hinges on data-link type, I think you make an important point.

what information needs to be propagated in the home?
since this is the homenet working group, we limit ourselves to getting the 
network layer functional.
that in my mind is: addressing, unicast routing, service discovery, external 
naming, other host configuration, and time.

unicast routing:
 - internal routes (assigned /64s and ULA)
 - SADR routes for PD prefixes
   (either explicit SADR or implied as part of prefix assignment)
 - More specific external routes (learnt via RFC4191 or other configuration)
   requires explicit SADR

addressing:
 - PD prefixes
 - ULA prefixes
 - whatever assigned prefixes required for the prefix assignment algorithm to 
function
 - meta data associated with prefixes (SAS/DAS policy, colour)

service discovery:
 - DNS zones for the bootstrapping the mDNS scheme

external naming:
 - I don't see how we can make this zero-conf. each border router could run 
hidden primaries for the reverse zone.
   if you get forward zones from the ISPs, then applications could update each 
of those primaries using DNS update.
   assuming we can bootstrap security. if the home has a vanity name, then the 
hidden primaries must run on
   some well known address in the home, and there has to be some agreement with 
either ISP or someone else
   to run secondaries.

other host configuration:
 - this is information learnt from external connections, homenet defaults and 
configuration provided by the user.
   basically externally learn from RA/DHCP, and passed transparently through 
the homenet, for homenet routers
   to propagate to hosts using DHCP/RA
 - DNS recursive resolvers
 - DNS server selection policy
 - SAS/DAS policy
 - NTP servers
 - whatever else is required for configuration of the network layer

we could put these into three different classes:
1) addressing / routing
2) configuration information for the homenet routers
3) configuration information for hosts
(that the homenet passes transparently from some source to hosts)

addressing and routing are inherently tided together. the home network is quite 
useless without either of them functioning.
if we look at a routing protocol as just a distributed database, it might not 
matter what we put into it, although it makes my tummy churn to think about 
embedding DHCP options into OSPF. ;-)

cheers,
Ole

 






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

>> You (and others) who speak of a "Homenet Configuration
>> Protocol" seem to be making an assumption which is far from
>> clear to me. That assumption is that config parameters in a homenet
>> will come in some sense top-down from a higher level source of
>> authority.
> 
> No, I don't think that's what's assumed. All the discussions I've heard have 
> been to have configuration sent around the home using a routing protocol, or 
> another protocol that disseminates information around the home in a similar 
> fashion.

absolutely. any protocol here must support multiple sources of information.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

Teco,

>>> My opinion: put the prefix distribution protocol on top of NDP, so all 
>>> nodes are informed.
>> 
>> what are the arguments for involving hosts in the prefix assignment protocol?
>> as opposed the existing router to hosts protocols (ND/DHCP).
>> 
> 
> With multiple prefixes, hosts have to select.

yes. there isn't that much information the network has that it can tell hosts 
though.
as long as the network routes the packets the right way, I'm going to be happy.

in more convoluted networks with walled gardens and VPNs, the network may pass 
the host more policy information, e.g. DNS server selection, SAS/DAS policy and 
so on.

> Hosts get smarter and know how to handle multiple paths (MPTCP and the like). 
> It isn't enough just to provide a prefix with lifetime. If the router knows 
> more, for example data rate and delay (fixed line, 3G/4G, whatever), it shall 
> pass it to the host.

as the hosts gets smarter they'll be able to figure out the best end to end 
path themselves.
the network may pass meta data associated with prefixes to the hosts. e.g. 
"usage of this prefix is horribly expensive".

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

Teco,

>>> There is something common on prefix distribution in Homenet, small 
>>> office/home office networks, branch office networks, ad hoc networks and 
>>> even in enterprise / campus networks. The prefix distribution protocol 
>>> could be a single protocol. We better not try to converge to a single 
>>> routing protocol.
>> 
>> how do you do a self-organizing / zero-conf network without making a choice?
> 
> I ment: We better not try to converge to a single routing protocol for 
> Homenet, small office/home office networks, branch office networks, ad hoc 
> networks and enterprise / campus networks.

OK, but at least we can pick a single routing protocol for the home.

> If distributed info semantics for prefix distribution are well defined, it 
> doesn't matter how it is delivered. Single encoding method helps, it is not 
> absolutely required. If a box faces two routing domains, it redistributes. 
> With DV style of flooding, this is simple and straightforward.

right. but we don't have to specify that in this working group, or at least not 
now.

> I still believe hosts shall be informed of information on border routers / 
> exit links and corresponding prefix information. And I prefer hosts shall not 
> have a need to snoop routing packets for that. Using a NDP extension is a 
> no-brainer for me.
> 
> So yes, Homenet shall select a single routing protocol for higher data rate 
> links (next to LLN routing, that one is separate).
> We can check how to run a prefix distribution protocol on top of routing, or 
> use another carrier (e.g. NDP).
> 
> My opinion: put the prefix distribution protocol on top of NDP, so all nodes 
> are informed.

what are the arguments for involving hosts in the prefix assignment protocol?
as opposed the existing router to hosts protocols (ND/DHCP).

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

>>> I can see reasons for having shared sub-layer for routing protocol and 
>>> prefix distribution protocol. As example, in MANET we have such already: 
>>> RFC 5444 and 5498. If we define a set of TLVs for border router information 
>>> and prefix distribution, it can run on whatever routing protocol. Don't 
>>> forget BGP.
>>> 
>>> For Homenet plug&play, I don't suggest to let configure grandma her 
>>> favorite IGP ;)
>> 
>> doesn't that mean we have to pick one?
> 
> At least one, for Homenet. Could be OSPF for high speed links, RPL for LLN, 
> or OLSRv2 for mix of wireless and wired links including ad hoc radio links.
> 
> There is something common on prefix distribution in Homenet, small 
> office/home office networks, branch office networks, ad hoc networks and even 
> in enterprise / campus networks. The prefix distribution protocol could be a 
> single protocol. We better not try to converge to a single routing protocol.

how do you do a self-organizing / zero-conf network without making a choice?

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

Mikael,

> So to continue this, even carrying service discovery information leads to new 
> information flow in that the routing protocol now needs to update a service 
> discovery "Information Base". At least this is less intrusive than having it 
> set interface IP addresses.

there is another choice to make here.
either the homenet 'control' protocol floods service discovery records, or it 
is used only to boot strap an  independent service discovery mechanism.

the hybrid mDNS proxy is an implementation using the latter approach.

SD has turned out to be a lot harder to solve than at least I thought it would 
be.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

Teco,

> I can see reasons for having shared sub-layer for routing protocol and prefix 
> distribution protocol. As example, in MANET we have such already: RFC 5444 
> and 5498. If we define a set of TLVs for border router information and prefix 
> distribution, it can run on whatever routing protocol. Don't forget BGP.
> 
> For Homenet plug&play, I don't suggest to let configure grandma her favorite 
> IGP ;)

doesn't that mean we have to pick one?

cheers,
Ole



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

Brian,

>> requirements from homenet-arch (I might have missed some):
>> - must support multi-homing
>> - each link should be assigned a stable prefix
>> - efficient allocation of prefixes
>> - should support both IPv4 and IPv6
> 
> I think you need to add
> - must allow source-address-based next hop routing

care to elaborate why you think so?
in my mind addressing != routing

> - must support multiple prefixes per subnet

yes, multiple "site prefixes", multiple assignments from the same site-prefix 
should be avoided though.

> - must guarantee consistency with routing
> 
> (The last one doesn't mean "must be provided by routing protocol",
> but it does mean that whatever box generates the PD message
> MUST be configured with the same information as the routers.)

absolutely.

> And also
> - must be zero-conf as far as the end user is concerned

yes. in the flow-chart I have that as "auto conf"

> I actually don't see how to separate this discussion (PD)
> from the discussion about how to announce multiple
> first-hop (a.k.a. default) routers.

I'm not quite sure what you mean by "announce multiple first-hop routers".
is it different than the multihoming support requirement?
with regards to terminology. I prefer prefix assignment (PA). and use 
delegation when the process is between different administrative domains.

> I also don't see how to separate it from the discussion
> of autonomic networking that is starting in NMRG, because
> of the zero-conf requirement.

possibly. there are a few autonomic related drafts submitted to homenet 
already. as far as I can see they are about building trusted adjacencies. 
(which could be a prerequisite for prefix assignment).

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

Dave,

> 1) in the multi-homing case you want requests from a local dns server
> to be sourced
>from the right network to the right ISP-provided forwarder. (think
> I have a fix for
>that but it involves abandoning resolv.conf for specific dnsmasq
> configuration.

I can't quite see how you can do that. given that typically the DNS lookup is 
done prior
to the choice of source address (choice of outgoing link).

RFC6731 specifies a policy that can be distributed to hosts. (which would 
typically go in a homenet protocol).
 it is unfortunate that in some VPN / walled garden scenarios there are split 
DNS, if it wasn't this wouldn't have been a problem.

I'm unsure what the right answer is with regards to using recursive resolvers 
outside of your own administrative domain.
DNS forwarders make an attractive target for surveillance.

cheers,
Ole




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

> I would like to clarify what is meant by "distribution of other configuration 
> information"? We're all talking about distributing prefixes, but what about 
> SIP and similar configuration parameters? In my opinion, it's not something I 
> would like to see being distributed in OSPF/IS-IS. It's just not something 
> routing protocols should be doing.

by other configuration information I was thinking of two types of information:
 - information that is required by the other routers in the home network.
   e.g. zone information required for hybrid mDNS proxies
 - information that is passed around to the routers, and then passed on to the 
hosts using RA or DHCP:
   e.g. DNS recursive resolvers, DNS server selection policy, SAS/DAS selection 
policy

I think there is an important 'scoping' here. the mechanisms here should be 
used to configure the function of the routers in the home network, and pass 
information to the hosts to configure the _network_ layer.

I don't quite see how you can (or should) configure applications this way.

cheers,
Ole


> 
> That being said, the alternative option is to define a new protocol... Over 
> the last year, I've been playing with the idea of a protocol that uses the 
> DNS idea of recursion (and discussing it with a couple of people). Let me 
> clarify with the example of a SIP server:
> 1. we have a SIP server at the ISP
> 2. my home has 7 cascaded HGWs and none of them know the address of the SIP 
> server
> 3. I want to connect my analogue phone to the sixth HGW and so this HGW needs 
> to find out the SIP server address - he therefore asks his upstream HGW (the 
> fifth in line) for it (of course, using this new and fancy protocol)
> 4. the fifth doesn't know it and asks the fourth, the fourth asks the third, 
> etc.
> 5. the first one (the one connected to the ISP) gets the request and requests 
> the ISP via DHCPv6 for it
> 6. upon receipt, the first forwards the information to the second, the second 
> tells the third, etc. until the 6th receives it and then I can use my phone
> 
> This approach would have to be worked on (what about multiple upstream links, 
> routing loops?), but I like it. It could be extended to support the 
> delegation of prefixes, active detection of "border" HGWs (when do you send 
> out DHCPv6?)...
> 
> Any thoughts?
> 
> Branimir
> 
> 
> 
> On Thu, Jan 30, 2014 at 2:18 PM, Mikael Abrahamsson  wrote:
> On Thu, 30 Jan 2014, Ole Troan wrote:
> 
> We need to decide, if we want prefix assignment and distribution of other 
> configuration information integrated in a routing protocol. Depending on that 
> decision we either need to design a separate protocol to do that, or we need 
> to add support for that in a routing protocol. Prefix assignment is simpler 
> with a link-state protocol, so that's why I have limited the choice of 
> routing protocols for that branch. I have assumed there is agreement to have 
> a single routing protocol in the home, and not support multiple.
> 
> I agree with the decision chart.
> 
> While I initially was very enthusiastic about integrating prefix assignment 
> into a routing protocol, I am now more sceptic to this approach.
> 
> So question if we don't use the routing protocol for prefix assignment, what 
> should go in there? Should we have a new protocol for service discovery? 
> Topology discovery? Anything else? Anyhow, the src/dst enhancements for the 
> IGP has to be done, I don't see much alternative to that.
> 
> Anyhow, I don't think DHCPv6-PD is a good method to assign prefixes to 
> interfaces.
> 
> -- 
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] DHCP PD (was: Homenet protocol decisions)

[Ole Troan]

Alex,

changing the thread since this seems to diverge from getting answers to the 
questions I asked.

cheers,
Ole


On 30 Jan 2014, at 13:55 , Alexandru Petrescu  
wrote:

> Pierre,
> 
> Thanks for the reply.
> 
> Le 30/01/2014 13:46, Pierre Pfister a écrit :
>> 
>> Le 30 janv. 2014 à 13:38, Alexandru Petrescu
>>  a écrit :
>> 
>>> Le 30/01/2014 13:28, Ole Troan a écrit :
>>>>>>> Could it be separate (existing) protocol?
>>>>>> 
>>>>>> if one had existed, sure. requirements from homenet-arch (I
>>>>>> might have missed some): - must support multi-homing - each
>>>>>> link should be assigned a stable prefix - efficient
>>>>>> allocation of prefixes - should support both IPv4 and IPv6
>>>>> 
>>>>> I meant this:
>>>>> 
>>>>> loosely coupled  separate (existing DHCPv6-PD) protocol
>>>>> triggering route updates to the routing protocol.
>>>> 
>>>> yes, DHCP PD comes up as a proposed solution quite frequently. I
>>>> just don't see how you can make DHCP PD fulfill the
>>>> requirements.
>>> 
>>> Well it does support multi-homing (Server allocates things to as
>>> many interfaces as needed), each link can be assigned a stable
>>> prefix (provided it triggers updates to the Routing protocol), the
>>> allocation is efficient (Server maintains dynamic databases,
>>> leases) and it supports both IPv4 ('IPv4 subnet allocation'
>>> RFC6656, DHCP transition et alia), and IPv6.
>>> 
>>> I miss something?
>> 
>> Well, in some cases DHCP seems to work, but not when you start
>> imagining multi-homed networks with multiple routers. Or maybe you
>> can tell me how to solve this situation with DHCP:
>> 
>> You have ISP1 connected with Router 1. ISP2 connected with Router 2.
>> Router 1, Router 2, and a third Router (Router 3), are connected on
>> the same link. ISP1 is delegated the prefix A/56 to Router 1. ISP2
>> is delegating the prefix B/56 to Router 2.
>> 
>> A host is connected behind Router 3.
> 
> Bear with me for a moment... is this topology what you meant?
> 
> 
>  ISP1   ISP2
>   |  |
>+---+  +---+
>|Router1|A/56  |Router2|B/56
>+---+  +---+
>   |  |
> --+---+--+--
>   |
>   |
>   +---+
>   |Router3|
>   +---+
>   |
> ++
> |Host|(how can it get an address from A, and from B)
> ++
> 
> 
>> How can it get addresses from both prefixes ?
> 
> Before I try to figure it out - is the above topology what is meant? 
> Something I misplaced?
> 
> Alex
> 
>> 
>> Cheers,
>> 
>> Pierre
>> 
>> 
>>> 
>>> Alex
>>> 
>>>> 
>>>> cheers, Ole
>>>> 
>>> 
>>> 
>>> ___ homenet mailing
>>> list homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

>>> Could it be separate (existing) protocol?
>> 
>> if one had existed, sure.
>> requirements from homenet-arch (I might have missed some):
>>  - must support multi-homing
>>  - each link should be assigned a stable prefix
>>  - efficient allocation of prefixes
>>  - should support both IPv4 and IPv6
> 
> I meant this:
> 
> loosely coupled  separate (existing DHCPv6-PD) protocol triggering
> route updates to the routing protocol.

yes, DHCP PD comes up as a proposed solution quite frequently.
I just don't see how you can make DHCP PD fulfill the requirements.

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

Alex,

>>> In my understanding, there is a need to couple the prefix assignment to the 
>>> routing protocol.  Although I am not sure how much tight, or what tight and 
>>> loose might mean.
>> 
>> to clarify what I meant:
>> tight coupling  --- integrated in a routing protocol, e.g. in 
>> draft-arkko-homenet-prefix-assignment
>> loosely coupled --- separate (new) protocol
> 
> Could it be separate (existing) protocol?

if one had existed, sure.
requirements from homenet-arch (I might have missed some):
 - must support multi-homing
 - each link should be assigned a stable prefix
 - efficient allocation of prefixes
 - should support both IPv4 and IPv6

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet protocol decisions

[Ole Troan]

> In my understanding, there is a need to couple the prefix assignment to the 
> routing protocol.  Although I am not sure how much tight, or what tight and 
> loose might mean.

to clarify what I meant:
tight coupling  --- integrated in a routing protocol, e.g. in 
draft-arkko-homenet-prefix-assignment
loosely coupled --- separate (new) protocol

cheers,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Source-specific routes in Linux [was: atomic updates...]

[Ole Troan]

Steven,

>>> We have switched to RA-Handling in userspace for similar reasons
>> already so I guess it's only the next logical step to create separate
>> routing tables for each upstream interface to do source-based routing
>> and filter out ULA-traffic on this layer instead of through iptables.
>> 
>> don't do it per upstream interface, that wouldn't work. per next-hop
>> might. the draft suggests a single table with source constrained
>> routers and backtracking.
>> 
> 
> Ah yes thanks for the hint. Please correct me if I got this wrong: I guess 
> per interface would be problematic if there are multiple routers on the 
> upstream link offering different prefixes. However in case of prefix 
> delegation via DHCPV6-pd like on usual home ISP connections would it not be 
> problematic to attribute the prefix to any specific router? - if there would 
> be multiple routers which I guess is unlikely in that situation. One could 
> maybe attribute the prefix to the source address of the DHCPv6 server but 
> that sounds problematic to me aswell. Hmm did I miss something or am I 
> completely on the wrong track now?

at least we're on the same track (and I think the correct one). ;-)

on the border router this is quite simple. if a border router uses PD and it 
discovers a default router on the same interface,
that will result in a SADR route (S, D) -> interface, next-hop. where S is PD 
prefix, D is ::/0, interface is the interface the PD was received
on and next-hop is whatever router discovery came back with.

the issue is with internal routers, where you may have an internal router 
connected to two exits on the same link, or behind another
IR that is connected to both..., i.e. arbitrary topology. 

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

Re: [homenet] Source-specific routes in Linux [was: atomic updates...]

[Ole Troan]

[...]

> We have switched to RA-Handling in userspace for similar reasons already so I 
> guess it's only the next logical step to create separate routing tables for 
> each upstream interface to do source-based routing and filter out ULA-traffic 
> on this layer instead of through iptables.

don't do it per upstream interface, that wouldn't work. per next-hop might. the 
draft suggests a single table with source constrained routers and backtracking.

> Having one central userspace management daemon for routing and address / 
> prefix delegation in general might not be the best or cleanest solution in 
> the end but I guess there is no better way right now.

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] Source-specific routes in Linux [was: atomic updates...]

[Ole Troan]

[...]

> We have switched to RA-Handling in userspace for similar reasons already so I 
> guess it's only the next logical step to create separate routing tables for 
> each upstream interface to do source-based routing and filter out ULA-traffic 
> on this layer instead of through iptables.

don't do it per upstream interface, that wouldn't work. per next-hop might. the 
draft suggests a single table with source constrained routers and backtracking.

> Having one central userspace management daemon for routing and address / 
> prefix delegation in general might not be the best or cleanest solution in 
> the end but I guess there is no better way right now.

cheers,
Ole

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

Re: [homenet] Source-specific routes in Linux [was: atomic updates...]

[Ole Troan]

Juliusz,

there is also a draft: http://tools.ietf.org/html/draft-troan-homenet-sadr-00

an implementation using Linux table support will require duplication of route 
entries into multiple tables.

cheers,
Ole


On May 7, 2013, at 14:03 , Juliusz Chroboczek  
wrote:

>>> If you're actually doing source-specific routing, please show me how
>>> you speak to the kernel.
> 
>> Most of that code is in Lua, and while I could have included
>> C extension module that did similar things as ip -6 does, I didn't
>> bother.
> 
> We're doing pretty the same in our prototype code (saying
> system("ip...") rather than speaking the netlink dialect of the day).
> Could you point us at the relevant code, please?
> 
>> So I'm just using ip -6 {route,rule} to set up source-specific rules
>> that map to destination tables.
> 
> Ah, okay.  So you're using rules, just as we found out (the hard way)
> that we need to do.
> 
>  http://www.spinics.net/lists/netdev/msg235316.html
>  http://www.spinics.net/lists/netdev/msg235346.html
> 
>> One (destination-based) routing table is maintained by routing
>> protocol, and the rest by Lua code which figures external defaults
>> based on routes within routing protocol implementation.
> 
> Nice hack.
> 
> -- Juliusz
> ___
> 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] Working Group Last Call for draft-ietf-homenet-arch-07

[Ole Troan]

Teco,

[...]

>> I don't think the homenet should get into the "policy" part of this, but 
>> rather just provide some simple tools/infrastructure.
> 
> Hmm.
> I also prefer simple tools/infrastructure. But let's try to solve some 
> problems, or at least we shall not block solving later on.

are the problems clearly understood at this point?
written down?

>>> I agree SADR is a major part of the right solution. Source address 
>>> indicates the provision domain, at least for IPv6. Hosts need to be updated 
>>> and mif should take the lead here. But mif only can take the job if the 
>>> network supports multiple provisioning domains well, e.g. SADR. Updated 
>>> hosts need SADR as well. 
>> 
>> I've always seen SADR as a network function. hosts would do RFC6724.
> 
> SADR on hosts is used quite often, where redundant links are in place.

that's not SADR. SADR is about _forwarding_ of packets.

[...]

> Back to the draft-ietf-homenet-arch WGLC: this provisioning domain topic is 
> not addresses very well. Question is if we will address it, hand it over to 
> mif, or cooperate where we focus on the (plug&play) network part and mif 
> takes the hosts.

I think we have a fair idea of how to deal with the home network being 
multi-homed. i.e. two or more connections to the Internet.
we also have a decent idea of how to deal with multi-homing to non-congruent 
networks, see draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05
I'm not quite sure what problem "multiple provisioning domains" is trying to 
solve outwith that.

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

Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07

[Ole Troan]

Teco,

> Still I am puzzled how we can support multiple provisioning domains with 
> multi-addressed hosts in a homenet. May I reference to the discussion in mif?
> http://www.ietf.org/proceedings/86/slides/slides-86-mif-1.pdf 
> 
> For providing information on provisioning domains, we might look into DHCP 
> _and_ ND. I think both can and should be supported. I think one of the 
> problems is how to merge or multiplex information from/for these provisioning 
> domains. Has DHCP a kind of ProvisioningDomain_ID on each (serf of) data 
> element(s)? On SAS/DAS policy, how to create such automatically in network 
> elements? If we can't on the fly, it might be irrelevant for homenet.

unmanaged and policy are at different ends of the scale. I don't know how you 
can do anything automatic with that.

in the homenet prototype I was talking about we implemented 
draft-bhandari-dhc-class-based-prefix-04.
where we attached a "colour" to each address prefix. this could then be used as 
a handle for SAS/DAS or for the application.
I don't think the homenet should get into the "policy" part of this, but rather 
just provide some simple tools/infrastructure.

> I agree SADR is a major part of the right solution. Source address indicates 
> the provision domain, at least for IPv6. Hosts need to be updated and mif 
> should take the lead here. But mif only can take the job if the network 
> supports multiple provisioning domains well, e.g. SADR. Updated hosts need 
> SADR as well. 

I've always seen SADR as a network function. hosts would do RFC6724.

there would be some gain in being able to signal hosts with routing 
information. not sure what that should be, unless we would just have hosts 
participate in the IGP.

> And of course the legacy stuff is out there.
> 
> Re-reading sections on multihoming (3.2.4, also 3.4.4), there is enough room 
> for solution space. I would expect some more guidelines form an architecture, 
> but now there are no constrains on what we may work out. That's fine.
> 
> May I suggest to add MPTCP (RFC 6824) at bottom of 3.2.4?

agree.

cheers,
Ole

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

Re: [homenet] ISP-delegated IPv6 prefixes (3.4.1) in draft-ietf-homenet-arch-07

[Ole Troan]

>> There is no real reasons for ISP's to only do /64s except spite the
>> customer.  The difference in costs from the RIRs for the bigger
>> address space is chump change even for developing states.  All their
>> equipment will support > /64 because the big players want to support
>> that.
>> 
> Actually, that's not quite right.  A number of ISPs are only offering /64s
> because a significant number of IPv6-supporting home routers can't handle
> shorter prefixes (although it's getting better) - we've seen this in our
> lab.  ISPs I've spoken with plan to offer shorter prefixes as home routers
> can support them.

right. changing the homenet architecture because of buggy software seems like 
putting the cart in front of the horse.

I heard about this bug years ago, wasn't aware it still existed in current 
gear. does it?

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

Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07

[Ole Troan]

Teco,

>>> Reading the homenet-arch, I can't find how multi-addressed hosts are guided 
>>> to prefer one address over another. I think such facility is beneficial in 
>>> multi-homed homenets.
>> 
>> the intention is to propagate the SAS/DAS policy given with 
>> draft-ietf-6man-addr-select-opt,
>> and more specific routes learn on the border, combined with source address 
>> dependent forwarding.
>> as well as rule 5.5 of 6724.
> This will work when every access router is a DHCP server, right? What if no 
> DHCP or DHCP-relay? Do we generate this option out of routing information? Or 
> some other zero-config magic?

I don't think there is any intention of creating SAS/DAS policy on the fly. I 
was only thinking of passing that along to hosts.
the homenet will using SADR ensure that BCP38 rules are satisfied. nothing more.

I'm not sure what you mean by the DHCP question. DHCP has an option to pass 
SAS/DAS policy to hosts. I'm not suggesting DHCP is used to propagate that 
information around between routers in the home net.

>> that's in solution space though. there is already a reference to the 
>> multihoming-without-ipv6nat document.
>> 
>> do you have ideas of anything else we should add to the architecture 
>> document?
> Maybe it is my reservations on the current suggested solutions. I don't 
> understand why we don't make use of ND. Then, access routers can provide 
> whatever they wish, from whatever source and the host can ignore or take some 
> benefits.

again I don't quite understand what you mean. which protocol is used to convey 
network information to the hosts doesn't much matter in my view...

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

Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07

[Ole Troan]

Teco,

> Reading the homenet-arch, I can't find how multi-addressed hosts are guided 
> to prefer one address over another. I think such facility is beneficial in 
> multi-homed homenets.

the intention is to propagate the SAS/DAS policy given with 
draft-ietf-6man-addr-select-opt,
and more specific routes learn on the border, combined with source address 
dependent forwarding.
as well as rule 5.5 of 6724.

that's in solution space though. there is already a reference to the 
multihoming-without-ipv6nat document.

do you have ideas of anything else we should add to the architecture document?

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

Re: [homenet] Naming and Service Discovery

[Ole Troan]

>> From the quoted draft: "for the purposes of this document, assume that
> each link has its own unique Unicast DNS domain name",
> which I don't think is acceptable in Homenet. I don't want my phone's
> name to change when I walk out to the shed.


in a service discovery world, would you even care about what the phone's name 
is?
does a name really have any meaning without a service associated with it?

let us assume that we don't want anyone to remember these names. the UI will 
present a list 
of available services, given where you are.

in that sense I really don't care what the domain name for my local link or 
site is either.
internally I don't use them, for access into my home when I'm outside I need to 
type in the externally visible
domain into my service discovery domain registry once.

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

Re: [homenet] Naming and Service Discovery

[Ole Troan]

> My understanding was that they were going to extend mDNS to work on
> multiple segments, rather than gluing mDNS "islands" with DNS... but I
> have not really followed the discussions in the mdnsext.

see:
http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01

cheers,
Ole

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

Re: [homenet] NPTv6-only home networks

[Ole Troan]

>> Stupid question:
>> Can we enforce requirements on host implementations as a result of
>> homenet?
> 
> We should avoid it wherever possible.

for service discovery that's pretty much unavoidable.

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

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

[Ole Troan]

>> Ok. I see it in the charter. I dont find it particularly appealing or worth 
>> a great trade off for the level of complexity involved. Especially if the 
>> tradeoffs require nat66 or something similarly complex
> 
> Touché.
> 
> Seriously, though, the point of routing in the home is that you really don't 
> want to bridge disparate media, and you want routers plugged together by 
> people who don't know about routing to create a happy, functioning network, 
> not a dysfunctional network that sort of works but is never satisfactory.

exactly.

the arguments I've heard are:
 - people just plug in whatever they bought, it must work regardless of being a 
router or a bridge
 - not all link-layers can be bridged together e.g. 802.15.4
 - problems with bridging links with very different speed characteristics e.g. 
802.11 and 1G wired
 - isolation between networks with different policy, e.g. guest networks, 
internal home automation, public wifi

cheers,
Ole

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

Re: [homenet] Egress Routing Discussion: Baker model

[Ole Troan]

Ray,

[...]

>>2. Aren't we forgetting the first hop?
>> 
>>Given a shared subnet/prefix/link with 2 CPE routers performing some
>>fancy new form of forwarding (based on PBR or SADR or whatever)
>>that is
>>also shared by existing host implementations, how will the routers
>>signal these new default route semantics to end hosts?
>> 
>>Would we need a new prefix information option in ND?
>> 
>>Would we need an extension to RFC 4191 Section 2.3 Route Information
>>Option to include (source prefix,destination prefix) routes?
>> 
>>Would we need a new ICMPv6 redirect message to extend RFC2461 Section
>>4.5 to include the possibility of (source,destination) redirects?
>> 
>> 
>> The beauty of this approach is that you don't need to signal anything
>> to the hosts for things to work properly. The hosts pick whatever
>> source address they choose and the network takes care of getting the
>> packet to the right exit.
>> 
> Don't understand. Maybe I'm being really dumb.
> 
> What about figure 2 of the Homenet Architecture? 
> 
>   +---+---+ +---+---+ \
>   |   Service | |   Service |  \
>   |  Provider A   | |  Provider B   |   | Service
>   |Router | |Router |   | Provider
>   +--++ +---+---+   | network
>  |  |   /
>  |  Customer|  /
>  | Internet connections | /
>  |  |
>   +--++ +---+---+ \
>   | IPv6  | |IPv6   |  \
>   | Customer Edge | | Customer Edge |   \
>   |   Router 1| |   Router 2|   /
>   +--++ +---+---+  /
>  |  | /
>  |  || End-User
> ---+-+---+---+--+--+---  | network(s)
>| |   | |  \
>   ++-+ +-++ ++-+ +-++  \
>   |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host |  /
>   |   H1 | |   H2 | |H3| |H4| /
>   +--+ +--+ +--+ +--+
> 
> Figure 2
> 
> 
> 
> IPv6 Host H1 will receive RA messages from R1 and R2, and add them both
> to the default router list (RFC2461 6.3.6).
> 
> IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with
> autoconfiguration and on-link flags set, and configure /64 prefixes from
> both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these
> as being on-link.
> 
> But IMHO there's no further AS number/provider information/upstream
> topology information coupled to these /64 prefixes. There might be a
> router-router interconnect LAN between R1 and R2, or there might not be.

if there is no interconnect between R1 and R2, then the host has two
interfaces connected to two separate connections. then I can't see how
that can be solved in the network. my assumption is that all homenet routers
must be connected (I see I haven't stated that anywhere, but that should be 
added).

> How will the host H1 know to associate source address prefixes from
> provider2 with router2 for off link destinations e.g. to a Provider2/56
> or Provider2/32?

in your case it will RFC6724, rule 5.5

> My expected host behavior would currently be that it'd just choose one
> of the known available default routers from the list. If correct fine.
> If not, then wait for an ICMPv6 redirect to be told to use the other router.

you would only get that if the routers were connected of course.
whichever came first, you'd either get a unreachable code 5 (wrong source)
or ICMP redirect, or the router would just forward the packet to second router.

> But the ICMPv6 redirect doesn't have any facility to include source
> prefix specific info: only a redirect for a destination prefix to use
> another router (for all source prefixes), not for a source/destination
> pair. In the situation depicted in Homenet Arch figure 2, there will
> almost certainly be two valid routes to e.g. www.google.com, one via
> each provider, with the correct 1st hop router dependent purely on the
> source prefix.

I agree, there is nothing useful the host learns from an ICMP redirect here.

> Even with RFC4191, the extension only provides routing information for a
> host to be able to select a default router based on the destination
> prefix, not an associated source prefix.
> 
> Are we saying that H1 should tightly couple source address selection
> with RA PIO & default router selection?

for directly connected hosts, we have that already. note that only applies when
hosts are connec

Re: [homenet] Egress Routing Discussion

[Ole Troan]

Fred,

> 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

to clarify, the SADR draft:
 - describes what source constrained / source address dependent routing is
 - describes a conceptual forwarding model
 - gives two alternatives to how a routers forwarding table can be populated.
   a) implicitly via other information learn from the prefix assignment protocol
   b) explicitly via one of the Baker extensions to routing protocols.

neither a nor b has any restriction to just the default route. more specific 
routes are supported too.
b allows flexibility to also advertise internal (S,D) routes, and S,D routes 
not associated with border routers.

I specifically chose single topology.

just to make it clear, I think the correct solution is to add support for (S,D) 
routes in the routing protocol,
I just don't want to sit on the fence and wait until that support is added and 
available.

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

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ole Troan]

Ray,

thinking out loud.

the border router includes in the advertisement of the aggregate prefix:
 - it's own global IPv6 address
 - list of external routes

each internal router:
 - installs (S,D) routes for all of the external routes with the border's 
global as next-hop.

normal unicast routing is used to get to the border.

yep, that should work too. and be completely independent of routing protocol. 
but at the cost of being dependent on the prefix assignment mechanism. leaving 
the question open I suppose, does SADR have a wider applicability outside of 
the home network...

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

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ole Troan]

Ray,

> I have read this draft and find it useful.
> 
>> A routing entry may have both  (S, D) paths and (*, D) paths.  The
> longest match wins
> 
> Section 5 seems to suggest SADR is just a tie breaker applied to the
> subset of equal length D routes, but I think you probably should be more
> specific on the phrase "longest match" in this sentence, as there are 2
> length comparisons (one on D and one on S)

yes, right now we say:

   "First a longest match lookup is done in the routing table for the
   destination address, then for the resulting set a longest matching
   lookup is done for the source address."

what if we also included some RIB entry examples?
e.g.

::/0 (route)
  2001:db8::/56 -> NH1 (path #1)
  2001:db9::/56 -> NH2 (path #2)
  -> NH#3 (path #3)

would that make it clearer?

> Section 6.2.
> 
> During autoconfig, if the prefix is delegated to other Homenet routers
> on a hop by hop basis, the Homenet router receiving a new prefix could
> indeed install a default SADR route for (parent_prefix/x,0:/0) -> the
> upstream delegating router. So in this case your requirement 2 to
> strongly couple autoconfiguration  and routing would not seem onerous.

right, in that case the parent prefix wouldn't really be the aggregate prefix 
though, and not
identify the border exit. in a strict routed hierarchy then I guess you 
wouldn't need SADR.

> But alternatively, if the delegation of prefixes within Homenet occurs
> via a mechanism like DHCP PD, the receiving router could instead install
> a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source
> address, and then recurse the standard unicast routing table to find the
> appropriate next hop toward the Homenet BR. This is a trick that works
> very well in BGP networks (with next BGP hop being a software/loopback
> interface of the AS egress router that is always up and stable, combined
> with an IGP containing just the loopback addresses of the BGP speaking
> AS egress routers)

yes, now we tie the aggregate prefix and the advertising border router using 
the router-id.
if the border router had a global address, that was included in the aggregate 
route advertisement
as well as the external route advertisements, we could use that instead.

it would certainly make the routing tables more clearer and more explicit.

> In which case there's no requirement for a hard link between the routing
> protocol and the prefix autoconfiguration mechanism, and thus no
> requirement to update the IGP to carry SADR routes, which I think is
> potentially a big win.

that would be a big win, but I don't quite see how you avoid the hard link?
given that border routers may or may not advertise a default route, and may 
also advertise
more specifics... 

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

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ole Troan]

David,

thanks for the thorough comments.

> nice to see this moving forward!  Comments below with section
> copy/paste.
> 
> On Mon, Feb 18, 2013 at 10:04:45PM +0100, Ole Troan wrote:
>>> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt
> [...]
>>> Filename:draft-troan-homenet-sadr
>>> Revision:00
>>> Title:   IPv6 Multihoming with Source Address Dependent Routing 
>>> (SADR)
>>> Creation date:   2013-02-18
>>> Group:   Individual Submission
>>> Number of pages: 7
>>> URL: 
>>> http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt
>>> Status:  http://datatracker.ietf.org/doc/draft-troan-homenet-sadr
>>> Htmlized:http://tools.ietf.org/html/draft-troan-homenet-sadr-00
> 
>> 4.  Using SADR for multihoming
>> 
>>   SADR is similar to policy based routing.  This memo proposes a simple
>>   extension to the destination based longest match algorithm to
>>   constrain it to source address.
>> 
>>   In order to support ingress filtering by upstream networks, the
>>   network MUST treat external routes specially.  Ingress filtering MAY
>>   also be used internally, by installing (S,D) routes for locally
>>   assigned prefixes, where the source prefix would be the aggregatable
>>   prefix.  If no ingress filtering is performed inside the network,
>>   then normal non-source constrained forwarding is used.
> 
> The last sentence seems to imply that, unless we have ingress filtering
> on Internal Routers, they don't use SADR forwarding.  This doesn't seem
> correct, shouldn't internal routers always use SADR to reach the
> correct border router?  There is probably just a "for local networks"
> missing before the last full stop.

yes, let me fix that.

>> 6.2.  Simplified SADR in home networks
> 
> (In general, I'm not sure this simplified variant is a good idea... but
> I don't have an opinion yet at this point.)

yes, it is a hack. it would allows us to proceed while waiting for SADR support 
in routing protocols though.

>>   In a home network using a dynamic prefix assignment mechanism such as
>>   [I-D.arkko-homenet-prefix-assignment] it may be known that a
>>   particular Border Router is announcing both an External Route and a
>>   Usable Prefix (for example, if the same router ID is announcing
>>   both).  In this case, interior routers may assume that the Acceptable
>>   Source Prefix of the External Route announced by that Border Router
>>   is in fact the Usable Prefix announced by that Border Router.
> 
> "the" sounds like a Border Router will only ever announce one such Usable
> Prefix.  Thinking of DSL/Cable routers with an USB UMTS/LTE dongle, this
> isn't sufficient.
> 
>>   An internal router when receiving a AS-External LSA route will
>>   install that in the routing table as normal.  When the internal
>>   router receives a usable prefix as part of prefix assignment, the
>>   router shall add source constrained entries to all the AS-External
>>   routes received from the same border router (matching router-ID).
> 
> To address aforementioned issue, this should probably read:
> 
>An internal router when receiving a AS-External LSA route will
>install that in the routing table as normal.  When the internal
>router receives one or more usable prefixes as part of prefix
>assignment, the router shall add source constrained entries to all
>the AS-External routes received from the same border router
>(matching router-ID), for each of the usable prefixes.

yes.

> (Wording in arkko-homenet-prefix-assignment was changed from "usable
> prefix" to "aggregated prefix" by the way)
> 
>>   Routes that are not associated with a border router or are not AS-
>>   External do not have source constrained paths.
>> 
>>   The routing protocol requirements for simplified SADR in the home
>>   network are:
>> 
>>   1.  Routing protocol must flood all information to all routers in the
>>   home network.  (Single area).
>> 
>>   2.  Prefix assignment and unicast routing must be done in the same
>>   protocol.
>> 
>>   3.  A router must be uniquely identified (router-id) so that router
>>   advertisements and prefix assignment can be tied together
> 
> 4.  All routers on the homenet MUST support simplified SADR routing.

I suppose that requirement applies generally, not only to the simplified 
variant.

> If 4. is not given, this scenario will lead to a loop:
> All links assumed at

[homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ole Troan]

Begin forwarded message:

> From: 
> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt
> Date: February 18, 2013 22:01:47 GMT+01:00
> To: 
> Cc: 
> Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no 
> with POP3 (fetchmail-6.3.20) for  (single-drop); Mon, 18 
> Feb 2013 22:02:13 +0100 (CET)
> Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com 
> (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 
> 2013 15:01:50 -0600
> Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by 
> rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +
> Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com 
> [72.163.7.178]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id 
> r1IL1ixR029679   for ; Mon, 18 Feb 2013 21:01:49 GMT
> Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com 
> with ESMTP; 18 Feb 2013 21:01:49 +
> Received: from localhost (localhost [127.0.0.1])  by ietfa.amsl.com 
> (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 13:01:48 -0800 (PST)
> Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com 
> [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlwPsnRC5mQw; Mon, 
> 18 Feb 2013 13:01:48 -0800 (PST)
> Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com 
> (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 13:01:47 -0800 (PST)
> Authentication-Results: rcdn-inbound-i.cisco.com; dkim=neutral (message not 
> signed) header.i=none
> X-From-Outside-Cisco: 64.170.98.30
> X-Ironport-Anti-Spam-Filtered: true
> X-Ironport-Anti-Spam-Result: 
> Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM
> X-Ironport-Av: E=Sophos;i="4.84,690,1355097600"; d="scan'208";a="89740088"
> X-Virus-Scanned: amavisd-new at amsl.com
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> X-Test-Idtracker: no
> X-Ietf-Idtracker: 4.40
> Message-Id: <20130218210147.7330.45442.idtrac...@ietfa.amsl.com>
> Return-Path: internet-dra...@ietf.org
> X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com
> X-Ms-Exchange-Organization-Authas: Internal
> X-Ms-Exchange-Organization-Authmechanism: 10
> Mime-Version: 1.0
> 
> 
> A new version of I-D, draft-troan-homenet-sadr-00.txt
> has been successfully submitted by Ole Troan and posted to the
> IETF repository.
> 
> Filename:  draft-troan-homenet-sadr
> Revision:  00
> Title: IPv6 Multihoming with Source Address Dependent Routing 
> (SADR)
> Creation date: 2013-02-18
> Group: Individual Submission
> Number of pages: 7
> URL: 
> http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt
> Status:  http://datatracker.ietf.org/doc/draft-troan-homenet-sadr
> Htmlized:http://tools.ietf.org/html/draft-troan-homenet-sadr-00
> 
> 
> Abstract:
>   A multihomed network using provider aggregatable addresses must send
>   the packet out the right path to avoid violating the provider's
>   ingress filtering.  This memo suggests a mechanism called Source
>   Address Dependent Routing to solve that problem.
> 
> 
> 
> 
> The IETF Secretariat
> 

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

Re: [homenet] prefix assignment on home networks

[Ole Troan (otroan)]

Mikael,

Given that we want multiprefix multihoming with multiple prefixes, SADR is 
pretty much the only solution. 

But consesus? Wouldn't dear getting anywhere close to that. :-)

Cheers,
Ole

On 15 Nov 2012, at 16:15, "Mikael Abrahamsson"  wrote:

> On Thu, 15 Nov 2012, Ole Trøan wrote:
> 
>>> Or am I missing things again?
>> 
>> no, this is pretty much what we imagined, and what Markus has implemented 
>> and showed at the IETF. the hosts would still do better if they support rule 
>> 5.5 when directly connected to the exits.
> 
> Absolutely, 5.5 is a plus and gives one less hop in the path, but at least 
> the packet will be ultimately delivered to its final destination.
> 
> So with the above "pretty much what we have imagined", is there consensus 
> that this is the way to go, or this is still being debated?
> 
> -- 
> 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] DHCP PD for homenets.

[Ole Troan (otroan)]

On 7 Nov 2012, at 14:50, "Teco Boot"  wrote:

> This should be in the homenet-arch, I think.
> 
> It sounds so obvious to me, that I described this in a short text in BRDP:
>   A Router should request a prefix for attached subnetworks, with
>   DHCP-PD [RFC3633], where there is at that moment no on-link prefix
>   for a selected Border Router.
> 
> I could make the should a MUST.

Disagree. Hierarchical or flat PD (with relays) don't work for multihomed 
sites, have problems with arbitrary topplogies etc. 

Cheers,
Ole


> 
> Teco
> 
> Op 7 nov. 2012, om 16:46 heeft Ted Lemon het volgende geschreven:
> 
>> I don't have a particular preference for DHCP-PD over OSPF in homenets, but 
>> I just wanted to quickly contradict what's been said by several people at 
>> the mic: that figuring out what prefix to delegate is hard.   It's not hard, 
>> actually―it's dead easy.   The reason folks think it's hard is because 
>> they're solving the wrong problem.
>> 
>> The problem that needs to be solved is how we number each home subnet.   The 
>> answer to this question is, "with a /64."   There is no other answer.   You 
>> never want to number a subnet with a /52.   Therefore, the delegating router 
>> should never delegate anything but a /64.   Problem solved.
>> 
>> I think the disconnect here is that people are thinking the routers to which 
>> prefixes are delegated need to themselves be delegating routers, but this is 
>> incorrect.   What they need to do is _relay_ prefix delegation requests to 
>> the delegating router from which they got their own delegation.
>> 
>> This scales to multi-homing with multiple delegating routers―you just relay 
>> every PD request upstream to all delegating routers.
>> 
>> I'd be happy to write a draft that describes how this works if someone 
>> actually wants it; I get the sense that people are pretty in love with the 
>> OSPF solution and would prefer not to be distracted, and I have no argument 
>> with that if that's the working group consensus.
>> 
>> ___
>> 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] New Version Notification for draft-howard-homenet-routing-comparison-00.txt

[Ole Troan]

> Can you provided a precise definition of "walled garden", as well as, define 
> the bi-directional connectivity rules with a few bullets (hopefully less than 
> 5). 
> I fear there may be more than one view of this (or possibly I'm the only one 
> ;^). 

I presume we are talking about multi-homing to non-congruent topologies.
as described here 
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03

not sure what exact problems with walled gardens would affect routing though. 

cheers,
Ole

>>> "Acee" == Acee Lindem  writes:
 The problem with zOSPF is that it doesn't meet our requirements.
 It doesn't detect borders (unless the border happens to have
 another zOSPF router with the wrong password),
>> 
>>   Acee> While this should be part of the solution, I don't see this as
>>   Acee> something that it necessarily should be built into the routing
>>   Acee> protocol.
>> 
 it requires configuration (for the password),
>> 
>>   Acee> How does any protocol do authentication w/o a shared key? If
>>   Acee> you don't do authentication, you don't need a key.
>> 
>> Yes, this is a general problem, which is why I keep asking what are our
>> real requirements here.
>> 
 it doesn't handle walled gardens (a requirement being debated),
>> 
>>   Acee> I don't fully understand this requirement and how it would be
>>   Acee> handled w/o configuration.
>> 
>> I don't understand this criticism.  Why are walled gardens different
>> than multiple ISPs?
> 
> 
> 
> 
> 
>> 
 it's not lightweight.
>> 
>>   Acee> A commercial router implementation supporting all the features
>>   Acee> including OSPF TE and VPNs is certainly not
>>   Acee> lightweight. However, I just downloaded the latest quagga
>>   Acee> suite and it is only about 21K there.
>> 
>> rtr3-[/usr/pkg/sbin] mcr 10007 %size ospf6d /usr/pkg/lib/libzebra.so.0
>>  textdata bss dec hex filename
>> 221476   113283132  235936   399a0 ospf6d
>> 272449   238483120  299417   49199 /usr/pkg/lib/libzebra.so.0
>> 
>> No all of libzebra might really be used.  So 11K code, plus up to 23K.
>> I think that half of the code can be ripped out (and I wish I had time
>> to do).
>> 
>> -- 
>> ]   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] draft-baker-homenet-prefix-assignment

[Ole Troan]

Michael,

> Is there some reason that the flooding mechanism can't distribute the
> list of edge CPE routers, and then DHCPv6 can be used in unicast
> request/reply to ask those CPE routers for things.
> 
> (I would even wonder if the CPE routers shouldn't be identified by their
> ULA rather than self-identifying by the address in the subnet the deal with)
> 
> This is how I imagined the DHCPv6 PD mechanism working before
> draft-chakrabarti-homenet-prefix-alloc-01 was written, which imagined a
> strict hierarchal tree.

that's how I imagined also.
DHCP PD on the edges. flooding protocol between all the internal routers. then 
hosts use RA/DHCP for addresses / other configurations to their onlink routers.

cheers,
Ole

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

Re: [homenet] draft-baker-homenet-prefix-assignment

[Ole Troan]

Ray,

> Actually, if you use another mechanism within the home there's a danger that 
> it might be worse: you then have potentially different semantics of leases 
> and possibly a lack of synchronization of timers: the lease on the ISP link 
> may expire, but locally assigned Homenet sub-leases not, leading to black 
> holes. Might become significant when changing providers or when providers 
> want to renumber.

you already have that. and from what I heard from UNH most CPEs got it wrong. 
(DHCPv6 PD lease timers must be mapped to RA PIO option life times).

cheers,
Ole

> 
> Fred Baker wrote:
>> I don't much care whose charter it's in. I do think that if we have an idea 
>> that an ISP will allocate an IA_PD to a directly attached router and that 
>> router will then, in some way, sub-allocate subnet prefixes to subnets in 
>> the home, then there is a case in which there are multiple ISPs that have 
>> separate routers doing that. Ralph and I have suggested using the same 
>> mechanism that ISPs use to allocate prefixes to the home to allocate 
>> prefixes within the home, which means having multiple DHCP servers. If we do 
>> it another way, whether ZOSPF's or some other way, we have the same problem 
>> in the sense that there will be multiple sources of subnet prefixes.
>> 
>> On Nov 16, 2011, at 2:56 PM, Ted Lemon wrote:
>> 
>>   
>> 
>>> On Nov 16, 2011, at 2:46 PM, Ole Troan 
>>>  wrote:
>>> 
>>> 
>>>> extend the DHCP protocol to handle multiple sources of information.
>>>>   
>>>> 
>>> I think this winds up being implicit in MIF's charter, although I didn't 
>>> realize that until quite recently.
>>> 
>>> 
>> 
>> 
>>   
>> 
> 
> -- 
> Ray Hunter
> ray.hun...@globis.net
> Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
> Registered at the KvK, Eindhoven, under number BV 17098279
> mobile: +31 620 363864
> 
> 

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

Re: [homenet] draft-baker-homenet-prefix-assignment

[Ole Troan]

Ted,

>> If we do it another way, whether ZOSPF's or some other way, we have the same 
>> problem in the sense that there will be multiple sources of subnet prefixes.
> 
> Yes.   This becomes an even uglier problem as you progress into the network, 
> because while at the edge you can tell that you are talking to two 
> administrative domains, as you move into the network past the first 
> delegating router, you wind up with a single DHCP server presenting the 
> merged configuration information from two administrative domains as if they 
> were a single administrative domain.
> 
> I thought I understood how to solve this problem before I started writing the 
> problem statement, and then when I remembered this aspect of it I kind of 
> flung my hands up in disgust.   I think the knowledge that there are two 
> separate administrative domains has to be visible throughout the network, but 
> this is really a substantial divergence from what DHCPv6, at least, currently 
> does.
> 
> I can certainly imagine extending DHCPv6 in a cascading prefix delegation 
> scenario where it signals this information down the cascade, but it's 
> conceptually quite a bit different.

that's exactly reasons why we have started looking at flooding type protocols 
in homenet as opposed to request/reply protocols.
it isn't only multiple sources and service discovery that is problematic with a 
request/reply protocol, it is also how it handles dynamism. something which was 
explored in the development of the DNS option for RA.

cheers,
Ole

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

Re: [homenet] draft-baker-homenet-prefix-assignment

[Ole Troan]

Fred,

 We need to be aware that not every network may be able to reach the
 Internet... So you might need to have an address from every available
 DHCP server, not just the "best," one, or even a "random," one.
>>> 
>>> Yes, this is part of a problem space of which I have become keenly aware 
>>> over the course of this IETF meeting.   Expect a draft shortly.   :)
>> 
>> do we need to?
> 
> Need to what? Provide a subnet number on each subnet?
> 
> Is that a real question?

extend the DHCP protocol to handle multiple sources of information.


cheers,
Ole

>> in a self organizing unmanaged home; if we were to do a combination of a 
>> network wide flooding mechanism and RAs. would we need DHCP in the network 
>> at all?
>> 
>> cheers,
>> Ole
> 

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

Re: [homenet] draft-baker-homenet-prefix-assignment

[Ole Troan]

>> do we need to?
>> in a self organizing unmanaged home; if we were to do a combination of a 
>> network wide flooding mechanism and RAs. would we need DHCP in the network 
>> at all?
> 
> I am not claiming that we do. However, the problem exists whether we do DHCP 
> in homenet or not. 

yes, indeed.

cheers,
Ole

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

Re: [homenet] draft-baker-homenet-prefix-assignment

[Ole Troan]

>> We need to be aware that not every network may be able to reach the
>> Internet... So you might need to have an address from every available
>> DHCP server, not just the "best," one, or even a "random," one.
> 
> Yes, this is part of a problem space of which I have become keenly aware over 
> the course of this IETF meeting.   Expect a draft shortly.   :)

do we need to?
in a self organizing unmanaged home; if we were to do a combination of a 
network wide flooding mechanism and RAs. would we need DHCP in the network at 
all?

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

Re: [homenet] draft-baker-homenet-prefix-assignment

[Ole Troan]

Ted,

>> The mic line was too long to bring this up:
>> You suggest using RFC 3633. How about RFC 2894 (Router renumbering) too?
>> Typo: the draft actually cites RFC 3363, which is not what you intended...
> 
> Ditto on the mic line—very frustrating.   I think you overestimate the 
> obstacles to using DHCPv6 PD for this application.   I don't think any 
> protocol extension is required.   What is needed is ad-hoc relay 
> configuration, which is already anticipated.   The CPE device can just 
> allocate a /64 for any PD it receives, and with ad-hoc relaying, it should 
> all Just Work.
> 
> The way ad hoc relaying works is that when you come up, your PD client asks 
> for a prefix on its upstream port.   If it receives PDs, it relays them on 
> its upstream port.   These PDs all wind up at the CPE device, which allocates 
> /64s to them and forwards them back, all in accordance with the existing DHCP 
> relay mechanism.
> 
> I think homenet would have to do a draft describing how to set this up, but 
> it does not require a DHCP extension.   There'd be some details to document 
> on how the routing topology gets set up; perhaps that could be done with OSPF.

- how do you discovery the DHCP server? do you require a hard-wired upstream 
port for this to work?
- what do you do with two routers on the same link, two separate prefixes? (or 
smart DHCP server (e.g. having the SPF))
- what do you with multiple sources of information? change the DHCP protocol so 
that a client picks _all_ servers, instead of
  the _best_ one?

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

Re: [homenet] another routing option

[Ole Troan]

Howard,

> I've said that I don't think we need a full dynamic routing protocol.  There 
> are other options for discovering an available path.  To stimulate creative 
> thinking, I've written a draft proposing one alternative that should be light 
> to implement in home gateways: 
> http://www.asgard.org/images/draft-howard-up-pio-00.txt
> If it is interesting, there's more work to be done on it; I could publish it 
> after the pre-meeting publication blackout ends.

aren't you in the end just going to reinvent RAs as a distance vector routing 
protocol...?

cheers,
Ole


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

Re: [homenet] Thoughts about ipv6 routing (babel & AHCP)

[Ole Troan]

>> but seriously, just remove it from the build.
>> 
> This I disagree with; 6to4 is seriously useful in certain environments
> (like mine).  Having it present can be useful, having it on by default,
> is problematic. Unless/until we can fully automate something else I want
> it available.

yes, I'm fine with that.

cheers,
Ole

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

Re: [homenet] Thoughts about ipv6 routing (babel & AHCP)

[Ole Troan]

Jim,

> Yes, his data was taken just before/as Comcast put its relays into
> production; it's not what we see on that network.  Before then, almost
> all traffic went through some poor server in Wisconsin, as I remember. 
> It sucked.
> 
> There is a self fulfilling prophesy here: if no one has decentr elays,
> then 6to4 is never usable, and then we should deprecate it.  If it is
> deprecated, why should anyone put in 6to4 relays?
> 
> Be that as it may, I suspect we should be more clever about whether it
> gets turned on automatically or not, maybe by whether the address is
> from an address range where we have some evidence of decent relays being
> available.

from a 6to4 router perspective you have no idea. the return relays are not 
under your control.
nor are they under your ISPs control.

in the homenet context you also need border discovery for this function. as you 
really do not want to
enable it on all internal routers. (in the case of global v4 addressing).

but seriously, just remove it from the build.

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

Re: [homenet] Thoughts about ipv6 routing (babel & AHCP)

[Ole Troan]

> However, overall trends on this list are discouraging.
> 
> 1) Getting IPv6 working well inside the home is a hard problem! It helps
> to actually try to make something work, to see the relevant details. I'd
> like it very much if at an upcomin
> 
> I've built 3 such networks, and am in the process of building several
> more - as well as making available code on a cheap, 120 dollar, platform
> to make it possible to actually go and set one up yourself to play with,
> so the more devilish, detailed problems become apparent. I've done my
> best to make sure 6to4, at least, works right out of the box. Native (no
> PD yet!) works pretty well, too - but getting the 6to4/ipv6 native to
> co-exist better is going to take slightly more work.

you aren't helping things work better by doing 6to4.
please disabled by default, if you absolutely want to support it at all, hide 
it somewhere under the Wizard menus.

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

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ole Troan]

Ted,

>> using the electricity network as an analogy, can we make a distinction 
>> between "safety" and "security"?
>> the electricity network in the home is somewhat self protecting with 
>> breakers and earthing.
>> a home network must protect 'itself', i.e. handle any device plugged into 
>> it, in any topology, external and internal attacks
>> and so on.
> 
> I am highly sympathetic to the desire not to try to solve this problem.   
> However, unfortunately network topology isn't the same as electrical 
> topology, for a couple of reasons.
> 
> The first reason is that electrical systems are generally set up by 
> professionals.   Yes, you plug devices into the electrical wiring of your 
> house, but someone skilled set it up (or if not, I hope you sleep in asbestos 
> pajamas).   The devices we are talking about are more analogous to circuit 
> distribution panels than to toasters.
> 
> The second reason is that electrical systems are essentially topology-free.   
> Any point on the system is essentially equivalent to any other.   This is not 
> true of a home network with routing.   What we are talking about is 
> essentially the possibility of rogue distribution panels intentionally or 
> accidentally being connected to your distribution system.   
> 
> Which is a result of the third reason: home networks are typically wireless, 
> or partially wireless, and so there is no physical security, unlike an 
> electrical network in a house, which is secure by virtue of being entirely 
> enclosed by the house.
> 
> I think what you are getting at is that we cannot be responsible for securing 
> the network.   And that is probably true.   But if the system doesn't have a 
> built-in mechanism for distinguishing between friend and stranger, the 
> autoconfiguration mechanism will create topologies that aren't desired, 
> either by accident or because a stranger wants access to the network.

I do agree with that.
I think we can figure out a way of "pairing" devices. whatever layer that ends 
up being done at.
it will be much more difficult to protect against hostiles injecting default 
routes, or pretending to be DHCP servers and so on.

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

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ole Troan]

> I've been reading the list with interest and have a question.
> 
> When various devices in the home figure out which does what,
> and do that periodically to handle changes, there's clearly
> the potential that a zombied host tries to try take over
> stuff with undesirable consequences.
> 
> My question is whether this group are planning to think
> about that now, or later, or never? (Or don't even think
> there's a problem worth attempting to address.)
> 
> Note - I'm not trying to argue for any particular level of
> security and certainly not for some unachievable fort knox
> everywhere, I'm just asking what's the plan?

can we explore some fundamental principles of how and what we need to "secure"?

using the electricity network as an analogy, can we make a distinction between 
"safety" and "security"?
the electricity network in the home is somewhat self protecting with breakers 
and earthing.
a home network must protect 'itself', i.e. handle any device plugged into it, 
in any topology, external and internal attacks
and so on.

I don't think it is the networks job to control who has access to the pictures 
of my grandmother or who can print to my printer. that's application policy.

is it the networks job to control who has access to the network? no, I think 
that is a layer 2 function.

I think homenet should focus on L3. (and be clear on what it expects from the 
other layers with regards to security).

cheers,
Ole



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

Re: [homenet] Homenet strawman slides

[Ole Troan]

Erik,

btw, "border discovery" needs to be done regardless of topology or prefix 
assignment solution choice.
on a border you (may) want firewall on, you want a ULA border, you want a 
organisational or site multicast border...

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

Re: [homenet] Homenet strawman slides

[Ole Troan]

Erik,

>> If all the ports are the same, no designated uplink, that is better.
> 
> While I can see that we can build the internals of the home network with 
> devices without a designated uplink (automatically configure prefixes, the 
> routing protocol etc), what I don't understand is how the connectivity to the 
> ISP would happen.
> 
> How do you see that working?
> Will each router try the protocols it would use against the ISP (PPPOE, DHCP 
> PD, etc) on every port? Or on every port where it doesn't find a OSPF (or 
> whatever home routing protocol we choose) neighbor? Or does the user have to 
> configure the Customer Edge Router to say "port eth0 is the WAN port?"
> 
> FWIW I haven't seen any discussion to try to automate this. The manual 
> configuration would be just as error prone as making the distinction between 
> the yellow WAN port and the blue LAN ports on current home gear.

this is the problem we named "border discovery" during the interim.
there were a few ideas of how that could be done. either implicit or explicit. 
nothing concluded, and I agree this is an important problem to tackle.

cheers,
Ole
___
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] 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