Re: [homenet] pervasive v4
On Tue, Nov 15, 2011 at 1:42 PM, Lorenzo Colitti lore...@google.com wrote: On Tue, Nov 15, 2011 at 09:42, Brian E Carpenter brian.e.carpen...@gmail.com wrote: If homenet is going to support arbitrary self-configuring topologies, and pervasive legacy IPv4 is required, we'd surely end up recommending NAT444-within-the-home as the only remotely practicable approach. Hans from D-Link suggests that another option is simply to bridge IPv4 packets and route IPv6 packets. To be very honest, if you have two D-Link router at home, you put one after another, it won't work today. I believe the problem is quite general a case to many NAT boxes today since they all share 192.168.0.0/24 or 192.168.1.0/24. So what I told Lorenzo is that, in that case I would like to disable NAT and route IPv6. Regards, Hans ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] secret sharing among devices
On Nov 15, 2011, at 5:10 PM, Joe Touch to...@isi.edu wrote: I'll remember that next time I login using the iPad to alter its config ;-) IETF geeks are not the target end user! :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] secret sharing among devices
Like wifi protected setup? Push button, pass phrase, near field coms and usb stick, recently reduced to push button and pass phrase. Not an ietf thing. - Original Message - From: Ted Lemon [mailto:mel...@fugue.com] Sent: Tuesday, November 15, 2011 03:19 AM To: Thomas Herbst Cc: Michael Richardson m...@sandelman.ca; homenet homenet@ietf.org; Thomas Herbst Subject: Re: [homenet] secret sharing among devices On Nov 15, 2011, at 6:40 PM, Thomas Herbst ther...@silverspringnet.com wrote: Ignoring the transfer mechanism for a moment, why would a home networking vendor put this on their products? The point of it is to prevent problems that would otherwise occur. For any home router that has hard-wired ethernet ports, we already have a potential solution to this problem that prevents accidental network merges, although I guess we'd have to talk someone in the IEEE into putting forth the actual 802.xxx protocol that would do what we need. The point is that two devices that haven't physically touched somehow hadn't ought to automatically form a network together. Believe me, if they do, that'll generate plenty of support calls. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] pervasive v4
+1 On Nov 15, 2011, at 12:49 AM, Lorenzo Colitti wrote: On Tue, Nov 15, 2011 at 11:04, Erik Nordmark nordm...@cisco.com wrote: On 11/14/11 6:19 PM, Brian E Carpenter wrote: Yes, but then we're extending v4 and expecting homenets to run (presumably) RIP. Why RIP? Same protocol between the home routers as we will pick for routing IPv6 in the home. The primitives you have to configure and renumber IPv6 hosts (multiple addresses, multiple RAs and address deprecation, and so on) are different from the ones we have in IPv4 (essentially, DHCPv4 and NAT). So I don't think we will be able to take what we do in IPv6 and apply it as-is to IPv4. Instead, I think we'll have to either NAT everywhere (like we do today) or bridge everywhere. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet smime.p7s Description: S/MIME cryptographic signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Comments on draft-acee-ospf-ospfv3-autoconfig-00
Lorenzo == Lorenzo Colitti lore...@google.com writes: Lorenzo 4. For security, I think we should pick an auth scheme and Lorenzo stick to it, otherwise Lorenzo it will just lead to fragmentation. Some pre-shared key Lorenzo scheme might be adequate; I don't know much about security Lorenzo so I don't really care what it is, but I do think we need Lorenzo to have one and it needs to be the same for Lorenzo everyone. I think we should say MUST here. So, let me go over the options in order to violently agree. 1) OSPF is multicast, so we can't use any bilteral key-agreement protocol on it's own. Statically keyed AH can be used for multicast traffic, and a router can trivially ignore an AH validation failure in order to provide some diagnostics by evaluating the contents of the OSPF frame. (This requires hacks on platforms that already have IPsec, but if you implement the AH inside the OSPF daemon) (so diagnostics can say, I saw router FOO on interface BLAH, but the key didn't match, so I ignored it, or even, I saw router FOO on interface BLAH, and since the key didn't match, I treated it as a guest network. What router FOO thinks of the packets it receives is an open question) 2) While we could invoke some kind of group-KMP, these essentially work out to a series of bilateral trust relationships which results in the master machine giving out the pre-shared secret in a secure fashion. The bilateral trust mechanism needs to be anchored by something, and you can invoke public key mechanisms, or... shared secret. Public key mechanisms with a leap-of-faith and then confirmation via UI, would be very cool, but completely exceeds our needs. 3) my understanding is that OSPFv3 eliminated the plain-text HELLO and md5 methods. The major thing we need to specify for zOSPF is that we need to pick a well-known SPI value for the AH header. That SPI value will need to specify an algorithm (HMAC-SHA1, HMAC-SHA2, HMAC-SHA3...) and perhaps a key length. We should publish a few choices for future interop, but we will need to pick one MUST for today. We can't really be resistant against a bid-down attack, but even HMAC-SHA1 is pretty resistant today (vs bare SHA1), and I think that we can count upon being able to specify HMAC-SHA3 for this work. -- ] 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 http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. pgpd7dddsM2V0.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] privacy vs subnet-id
Brian == Brian E Carpenter Brian writes: Brian The responsible parent, for example, who does not want to Brian be fined for their kid's illegal downloads. So, something that we could specify is some way to name the subnets, and to communicate from the CPE router to the ISP about what is what, particularly in the case where the CPE router is provided by and/or partially managed by the ISP. The goal here is to give the ISP some information the network topology so that the ISP and the responsible parent can more easily work out who is being complained about. Said communication doesn't necessarily mean a protocol between the CPE router and ISP (although it could via INCH or MILE). It could be as simple as deciding upon a clear human readable textual description of the network, something the responsible parent can copypaste from a web interface to an email with the ISP. -- ] 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 http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] privacy vs subnet-id
Once HomeNet is figured out, a real subsequent challenge will be to address how to translate any leftover configuration required for the end user. This would be anything we couldn't figure out how to auto-configure. By translate I mean translating any geek-speak config concepts into equivalent mass market concepts that can be easily grasped by the average consumer. If we can't figure this out, and the resulting model has too much policy or buttons and levers to manipulate, then we're probably setting up a nice managed service offering for an NSP. Randy On Nov 15, 2011, at 7:36 AM, Michael Richardson m...@sandelman.ca wrote: Brian == Brian E Carpenter Brian writes: Brian The responsible parent, for example, who does not want to Brian be fined for their kid's illegal downloads. So, something that we could specify is some way to name the subnets, and to communicate from the CPE router to the ISP about what is what, particularly in the case where the CPE router is provided by and/or partially managed by the ISP. The goal here is to give the ISP some information the network topology so that the ISP and the responsible parent can more easily work out who is being complained about. Said communication doesn't necessarily mean a protocol between the CPE router and ISP (although it could via INCH or MILE). It could be as simple as deciding upon a clear human readable textual description of the network, something the responsible parent can copypaste from a web interface to an email with the ISP. -- ] 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 http://www.youtube.com/watch?v=kzx1ycLXQSE 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] Comments on draft-acee-ospf-ospfv3-autoconfig-00
Hi Acee, On 11/14/2011 10:11 PM, Acee Lindem wrote: On Nov 14, 2011, at 9:46 PM, Lorenzo Colitti wrote: On Tue, Nov 15, 2011 at 10:25, Acee Lindem acee.lin...@ericsson.com mailto:acee.lin...@ericsson.com wrote: 1. I think the OSPFv3 router ID should not be based on the MAC address because that will encourage people to assume it's unique most of the time. I think we should just make it a pseudo-random number so it's clear that uniqueness is only guaranteed by collision detection and that collision detection needs to be robust. The draft requires duplicate Router-ID detection and resolution. I don't think that the fact that a portion of the MAC address is used as a first try is reason for this detection/resolution not to be implemented or tested. In my experience, giving people something that works most of the time will cause the cases where it doesn't work to break. I think it's better to explicitly provide no guarantees of uniqueness to make it clear that collision detection needs to be robust. In the OSPF WG, the fact that a mechanism is specified implies that it is required to be robust. Also, if we rely on collision detection, then what's the advantage of using the MAC address? We might as well as make it random all the time - that probably has a lower chance of collision anyway. I can't disagree with this argument and think we could go with a psuedo-random number seeded with a hash on the hardware fingerprint as the first try for router-id. As a side note, what's your opinion on citing and suggesting/requiring http://tools.ietf.org/html/rfc5642#section-4 for manageability? Thanks, -- Carlos. I think you mean virtual links. They are definitely not needed in the auto-configured environment as they are for providing a backbone path through a transit area and the OSPFv3 auto-configured routing domain assumes only a backbone area. Yes, virtual links. Do we need to state explicitly that they cannot exist and are not supported? Since the auto-configured routing domain is area 0 only, it is explicit. 3. Can we use normal LSAs to detect collisions? One idea would be if you see your own router ID in the list of neighbours of a network LSA or router LSA, then there is a collision. Will that work? If so we wouldn't need the hardware fingerprint at all. No. In an arbitrary topology, A router with a duplicate router-id can be multiple hops away. Yes, but router and network LSAs are flooded, so you'll hear them regardless of whether your duplicate is multiple hops away, no? Both OSPFv3 and OSPFv2 would consider an unrecognized self-originated LSA, i.e. having our Route-ID, as a stale LSA and purge it. This is a very basic mechanism of OSPF. I'd rather use a separate mechanism for duplicate Router-ID detection. I considered techniques involving the encoding some additional information in the Router-LSA but these all seemed to be hacked. If the pre-shared key is hard-coded, it is no better than the OSPFv3 Interface Instance ID that is specified to prevent inadvertent adjacencies with routers not supporting the auto-configuration. If configuration of a pre-shared key is required, you no longer have auto-configuration. Sorry, that wasn't clear. What I meant to say is that we should pick one scheme (e.g., HMAC-SHA) and stick to it; we shouldn't support multiple schemes as that will lead to interoperability issues for devices that use one scheme and devices that use another scheme. The OSPFv3 Instance ID is part of the base OSPFv3 specification and I think it is a very good mechanism to prevent inadvertent adjacencies. If we need real authentication, we'll need a pre-shared key. I don't see any advantage of authentication with a well-known pre-shared key to prevent inadvertent adjacencies. Thanks for the comments, Acee ___ 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] Comments on draft-acee-ospf-ospfv3-autoconfig-00
Hi Michael, On Nov 15, 2011, at 10:26 AM, Michael Richardson wrote: Lorenzo == Lorenzo Colitti lore...@google.com writes: Lorenzo 4. For security, I think we should pick an auth scheme and Lorenzo stick to it, otherwise Lorenzo it will just lead to fragmentation. Some pre-shared key Lorenzo scheme might be adequate; I don't know much about security Lorenzo so I don't really care what it is, but I do think we need Lorenzo to have one and it needs to be the same for Lorenzo everyone. I think we should say MUST here. So, let me go over the options in order to violently agree. 1) OSPF is multicast, so we can't use any bilteral key-agreement protocol on it's own. Statically keyed AH can be used for multicast traffic, and a router can trivially ignore an AH validation failure in order to provide some diagnostics by evaluating the contents of the OSPF frame. (This requires hacks on platforms that already have IPsec, but if you implement the AH inside the OSPF daemon) (so diagnostics can say, I saw router FOO on interface BLAH, but the key didn't match, so I ignored it, or even, I saw router FOO on interface BLAH, and since the key didn't match, I treated it as a guest network. What router FOO thinks of the packets it receives is an open question) 2) While we could invoke some kind of group-KMP, these essentially work out to a series of bilateral trust relationships which results in the master machine giving out the pre-shared secret in a secure fashion. The bilateral trust mechanism needs to be anchored by something, and you can invoke public key mechanisms, or... shared secret. Public key mechanisms with a leap-of-faith and then confirmation via UI, would be very cool, but completely exceeds our needs. 3) my understanding is that OSPFv3 eliminated the plain-text HELLO and md5 methods. The major thing we need to specify for zOSPF is that we need to pick a well-known SPI value for the AH header. That SPI value will need to specify an algorithm (HMAC-SHA1, HMAC-SHA2, HMAC-SHA3...) and perhaps a key length. We should publish a few choices for future interop, but we will need to pick one MUST for today. We can't really be resistant against a bid-down attack, but even HMAC-SHA1 is pretty resistant today (vs bare SHA1), and I think that we can count upon being able to specify HMAC-SHA3 for this work. We will soon have non-IPsec authentication for OSPFv3: http://www.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-10.txt The point that I don't understand from this E-mail thread is where the Security Association (SA) comes from to use for auto-configured OSPFv3 routers? I guess it is from a USB flash drive ;^)). Also, are you and Lorenzo suggesting we make authentication MANDATORY in for auto-configured OSPFv3 routers? Thanks, Acee -- ] 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 http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] privacy vs subnet-id
On Nov 16, 2011, at 2:49 AM, Michael Richardson m...@sandelman.ca wrote:
{why am I top-quoting?}
I don't know.
So, I agree with you about translating terminology, or at least, picking
sufficiently unique (and multicultural) terminology such that the terms
can be used unambiguously.
The scenario I have in mind is:
1) ISP gets an abuse complaint about IP
2001:DB8:f00d:5634:0243:60ff:fefa:8842
2) ISP maps this via 2001:DB8:f00d:56/56 to customer FOO.
3) ISP contacts customer FOO about this issue, noting that
it's on subnet-id 34. No end-user is going to know
what 34 is, nor what 0243:60ff:fefa:8842 is, and
given privacy extensions, that might be more random.
So the question is, can we have a way for CPE router to unambiguously
record/communicate that subnet-id is 34 was assigned to wifi guest
network on ESSID garage-party.
It would certainly be handy if the homenet populated a reverse DNS tree that
could be queried.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] secret sharing among devices
On Nov 15, 2011, at 9:48 PM, Thomas Herbst ther...@silverspringnet.com wrote: Like wifi protected setup? Push button, pass phrase, near field coms and usb stick, recently reduced to push button and pass phrase. Into which router do you type he pass phrase? How? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] secret sharing among devices
Joe == Joe Touch to...@isi.edu writes: Joe - verizon home network (no USB on my home router) Joe - iPhone and iPad (USB clients, but not hosts) Joe - no PC (use the iCloud service) Tell me again why you need homenet on such a simple network? Joe So my iPad (and/or anything else in the house) can use either Joe the verizon path or the iPhone path to the Internet with Joe automatic routing. At this point, it is still a flat LAN with two exit paths. It's also WIFI. If it was secured WIFI, then you already entered keys into all devices, so actually, we are probably done. So, it's not secured WIFI. The network is open. Should we have any security enabled at all then? Joe If it's too simple, add other routers that still don't have Joe USBs or cameras. I agree that it's a problem, but it's not clear to me that it's a real problem. I think that USB ports are becoming ubiquitous. -- ] 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 http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] pervasive v4
On Nov 16, 2011, at 7:52 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: But afaik this isn't the 'make IPv4 work better' WG. That means that the requirement to not break IPv4 actually constrains the possible topologies for IPv6. This was definitely not the sense of the working group in the meeting. The sense of the working group was if the IPv6 topology works, but the IPv4 topology doesn't, oh well. The consensus seemed to be that it was better to make IPv6 work well than to constrain the solution so that topologies in which IPv4 wouldn't work would also break IPv6 (which, let's be clear, is essentially what you are suggesting). Having said that, if there's a way to make IPv4 topologies that either don't work, or work poorly, with a modern IPv4 NAT router, work well with a homenet router, and it's possible to get that essentially for free, then I think it's worth getting, even though that's certainly not the problem we've set out to solve. And I think what a couple of people have been saying here (with which I agree) is that it is in fact possible to get this essentially for free. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] pervasive v4
On Nov 16, 2011, at 9:00 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: What will happen if a user hangs an existing v4-only box bought in the supermarket off a new homenet-conforming box? I'm not saying we have to guarantee that it works, but at least we need to understand the possible breakages (IMHO). Sure. In point of fact, it will work just as well as if they did the same thing with a non-homenet-conforming box, and possibly better. In some cases that means it will work; in some cases it means it will not. IOW, homenet won't make things worse. So it's hard to accept the notion that, in the event that IPv4 breaks in this case, IPv6 ought to break as well. Of course, since this is a non-homenet router, possibly it doesn't support IPv6 anyway. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
Right now clients don't pick the best one--they just pick one pretty much at random. But yes, if you have two DHCP servers providing different information, you need to resolve that. We would have to write a spec to handle this—it's not handled in the existing protocol. 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. For instance, your computer might talk to the power company, but the power company doesn't want to transit your internet traffic. I'm not saying this is a certainty, only that we need to think about it somehow. :-) Russ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
On Nov 16, 2011, at 11:18 AM, Russ White ru...@riw.us wrote: 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. :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
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] pervasive v4
On Nov 16, 2011, at 1:31 PM, Erik Nordmark nordm...@cisco.com wrote: The service call will be something like the internet is working fine, but the printer is broken when the laptop uses dual-stack but the printer is IPv4 only. I uniformity (within the home) is better if we care about complexity. This is certainly a valid point, but you've got it backwards, since we're talking about bridging IPv4. The real risk is that a bonjour printer will work only if you are plugged into the same router it is. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
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] pervasive v4
Good points...Speaking of Bonjour, I haven't seen many references to support for multicast (yet)...I'm assuming this is on the plate. Randy On Nov 15, 2011, at 10:29 PM, Ted Lemon wrote: On Nov 16, 2011, at 1:31 PM, Erik Nordmark nordm...@cisco.com wrote: The service call will be something like the internet is working fine, but the printer is broken when the laptop uses dual-stack but the printer is IPv4 only. I uniformity (within the home) is better if we care about complexity. This is certainly a valid point, but you've got it backwards, since we're talking about bridging IPv4. The real risk is that a bonjour printer will work only if you are plugged into the same router it is. ___ 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] pervasive v4
On 16 Nov 2011, at 14:35, Randy Turner wrote: Good points...Speaking of Bonjour, I haven't seen many references to support for multicast (yet)...I'm assuming this is on the plate. Yes, it was one of the topics of discussion at the interim, mostly in the context of naming and service discovery. There hasn't really been any discussion on the use of multicast as a high bandwidth streaming system. Ray ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
On Nov 16, 2011, at 1:52 PM, Ole Troan wrote: 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? 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
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] pervasive v4
Was the intent of naming and discovery to try and reuse the zeroconf/mdns stuff or something new? Thanks! Randy Original message Subject: Re: [homenet] pervasive v4 From: Ray Bellis ray.bel...@nominet.org.uk To: Randy Turner rtur...@amalfisystems.com CC: homenet@ietf.org homenet@ietf.org On 16 Nov 2011, at 14:35, Randy Turner wrote: Good points...Speaking of Bonjour, I haven't seen many references to support for multicast (yet)...I'm assuming this is on the plate. Yes, it was one of the topics of discussion at the interim, mostly in the context of naming and service discovery. There hasn't really been any discussion on the use of multicast as a high bandwidth streaming system. Ray ___ 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
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 o...@cisco.com 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
On Nov 16, 2011, at 3:41 PM, Fred Baker f...@cisco.com wrote: 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
