Re: [homenet] Homenet protocol decisions
Lorenzo Colitti wrote: On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan otr...@employees.org mailto:otr...@employees.org wrote: We need to decide, if we want prefix assignment and distribution of other configuration information integrated in a routing protocol. I think the two should be in the same protocol, because routing and addressing are tightly coupled. Fundamentally, there is no point in configuring an address on a host if the homenet doesn't have reachability to it - because you can't use that address to talk to anyone else in the homenet. If the routing protocol and the prefix distribution protocol are separate, then they can end up with different ideas on what prefix is on a given link. That will lead to blackholing. +1 I don't see how you're going to avoid tight coupling and still keep things stable when/if provider links and internal links flap. IMHO there's got to be some form of fate sharing to avoid every single app having to implement a version of happy eyeballs. -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
On Feb 3, 2014, at 3:19 PM, Michael Richardson wrote: I am most worried that we really have no process here to make a decision. How about rough consensus and running code? - Mark -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Le 02/02/2014 17:47, Acee Lindem a écrit : I agree. I disagree questioning what happens when the routing protocol finds out that even though the delegation protocol things everything is ok and addresses were delegated justfine the network becomes partitioned. First, I would try to understand what is meant by partitioned network. I have heard this term in the MANET/AUTOCONF discussion as well; there it was high level just to give a feeling about how a network would become disconnected. But less of a real experience. Then, a delegation protocol (DHCP-PD, see the other threat), is guided by a pre-configured database. That database should be in sync with the routing protocol pre-configured database. If these two files are not sync'ed then it's the planners fault. Or otherwise automatic means exist to make them be in sync. Also, plugging the DHCP prefix delegation protocol into the routing protocol would be a two-way process, not just one=way: DHCP-PD would inform the routing protocol daemon about the allocation, subsequently this latter would update some local routes; but also - if the routing protocol finds there are some loops then it reports an error to the DHCP PD daemon. One should also take into account that a routing protocol doing prefix delegation at the same time as DHCP-PD (without knowledge one of the other) is probably goign to become a source of contention. Also, since we already have to bootstrap an auto-configuring routing protocol, why not leverage this work to distribute other information? I do not disagree with this. I think it is meaningful direction as well. Alex Acee On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr mailto:j...@pps.univ-paris-diderot.fr wrote: And what happens when the routing protocol finds out that, even though the delegation protocol thinks everything is OK and addresses were delegated just fine, the network is now partitioned? How do you reassign addresses in that case? I fail to see how this particular functionality requires merging the two protocols. If a link is partitioned, you need to time-out the address assignments made by the now unreachable router. Whether they are timed out by the routing protocol or by a separate configuration protocol is pretty much an implementation detail, isn't it? The routing protocol knows that the network is partitioned because that's what it does. How is the configuration distribution protocol going to know that? Either you couple it to the routing protocol, or you have it poll to see if things have changed (inefficient and/or slow to notice changes). Why would you do the latter? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
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
Brian E Carpenter brian.e.carpen...@gmail.com wrote: 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. I'm not sure that he is making this assumption. There are clearly sources of authority for various things: the border router(s) know about the services from the ISP(s) they are connected to. I might also say, the printer knows that it is a printer, but that already a solved problem. The key thing is that some component knows that the local zone is carpenterhouse.example.com, and may let the printer know that, so that it can advertise that name into the right places. I think we need a completely different approach. Just by chance, I happen to have one in mind. It's discussed for the case of carrier networks in http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 I believe that exactly the same approach is needed for homenets. I read the beginnging of the document, and it seems in sync with with Juliuz is actually talking about. I did not find enough motivation in the document for what is desired. I am also skeptical that there are significant configuration things in the homenet which ultimately need to share fate with connectivity. I am most worried that we really have no process here to make a decision. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpSJu308Vwjv.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: As usual, it's a tradeoff, and the choice of tradeoff is dependent on one's background. Those of us who come from the Free Software chaos will prefer small, self-contained protocols that can be implemented by small, loosely coupled groups of developers, and that communicate through well- defined, stable APIs. Yes, I've lived in this space for 20+ years. In that space, we still don't have a DHCP client which can sensibly interact with an 1X supplicant in order to get me on a network which has a working layer-3 uplink, even though the layer-2 signal strength is not the strongest. (I call then NOTworks, an AP sitting somewhere with a broken DSL link) NetworkManager and its equivalent in Android is closest we have gotten, and there are still significant issues: they are getting better, but it hasn't been fun. And it's not the size of the protocol that really matters. One problem that the free software chaos suffers from is that much of the tools that we have (quagga, ISC DHCP, for instance) are designed by big organizations for big organizations. Those who come from large, well-managed, centralised organisations will prefer large protocols, and won't want to bother with the tricky job of defining stable interfaces between loosely coupled software components. I think that are significantly overstating this situation. Big organizations are seldom well organized or well managed, and they hate forklift upgrades, so they actually prefer small incremental additions as well. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpDNghECo1au.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
On Feb 3, 2014, at 10:00 AM, Michael Richardson mcr+i...@sandelman.ca wrote: I am also skeptical that there are significant configuration things in the homenet which *do not* ultimately need to share fate with connectivity. ULA seems like an obvious example. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
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
You (and others) who speak of a Homenet Configuration Protocol seem to be making an assumption [...] that config parameters in a homenet will come in some sense top-down I don't think we are. (But you're right, this deserves stating explicitly.) I think that most of us have in mind a peer-to-peer protocol in which authoritative configuration information (notably prefix information) is flooded by the edge routers (CPEs), and dynamic information is negotiated dynamically both on a link-local basis (agreeing on a single prefix) and globally to the homenet (ensuring unicity). (I'm assuming just site-local unicast and multicast, hence the need for an application- layer flooding algorithm, I'm not sure if others are assuming site-local multicast.) As far as I am aware, this is the same model as the one in Acees' draft, except for the use of a flooding mechanism separate from OSPF's, and is in full agreement with the Arch document. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
I agree. Also, since we already have to bootstrap an auto-configuring routing protocol, why not leverage this work to distribute other information? Acee On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.frmailto:j...@pps.univ-paris-diderot.fr wrote: And what happens when the routing protocol finds out that, even though the delegation protocol thinks everything is OK and addresses were delegated just fine, the network is now partitioned? How do you reassign addresses in that case? I fail to see how this particular functionality requires merging the two protocols. If a link is partitioned, you need to time-out the address assignments made by the now unreachable router. Whether they are timed out by the routing protocol or by a separate configuration protocol is pretty much an implementation detail, isn't it? The routing protocol knows that the network is partitioned because that's what it does. How is the configuration distribution protocol going to know that? Either you couple it to the routing protocol, or you have it poll to see if things have changed (inefficient and/or slow to notice changes). Why would you do the latter? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Also, since we already have to bootstrap an auto-configuring routing protocol, why not leverage this work to distribute other information? As usual, it's a tradeoff, and the choice of tradeoff is dependent on one's background. Those of us who come from the Free Software chaos will prefer small, self-contained protocols that can be implemented by small, loosely coupled groups of developers, and that communicate through well- defined, stable APIs. Those who come from large, well-managed, centralised organisations will prefer large protocols, and won't want to bother with the tricky job of defining stable interfaces between loosely coupled software components. To put it differently -- with Dave's help, we should have no trouble pushing a self-contained configuration daemon into OpenWRT and from there to other Linux and BSD systems. We will find it somewhat more challenging to add the proposed sub-protocol to all of the Open Source implementations of OSPF and ensure that it's compiled-in by default. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
On Sun, Feb 2, 2014 at 8:47 AM, Acee Lindem acee.lin...@ericsson.com wrote: I agree. Also, since we already have to bootstrap an auto-configuring routing protocol, why not leverage this work to distribute other information? Because routing protocol authors are generally hostile to adding what is effectively dhcp-like support to their protocols and daemons? Acee On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: And what happens when the routing protocol finds out that, even though the delegation protocol thinks everything is OK and addresses were delegated just fine, the network is now partitioned? How do you reassign addresses in that case? I fail to see how this particular functionality requires merging the two protocols. If a link is partitioned, you need to time-out the address assignments made by the now unreachable router. Whether they are timed out by the routing protocol or by a separate configuration protocol is pretty much an implementation detail, isn't it? The routing protocol knows that the network is partitioned because that's what it does. How is the configuration distribution protocol going to know that? Either you couple it to the routing protocol, or you have it poll to see if things have changed (inefficient and/or slow to notice changes). Why would you do the latter? Several comments: 1) The synchonicity problem exists for multiple layers of the stack. Take DNS for example, when addresses change, dns needs to change also. It's very hard with any form of centralized server for dns to make that fast or atomic. 2) All the interdependencies on config and routing and dns for a highly dynamic ipv6 world are forcing daemon writers to adopt a software bus structure to broadcast and respond to changes to various subsystems controlled by various daemons. In the linux world at least, system configuration information is propigated between daemons mostly along the dbus, and the openwrt folk have implemented a ubus that is lighter weight, that communicates between dhcpv6, dns, dhcpv4 and other daemons. So what's needed is a clear delination of responsibilties for acquiring and pushing out changes to the underlying network architecture, and it doesn't matter what protocol on the wire those run over. 3) So far in dealing with highly dynamic ipv6, and poor interfaces to DNS in particular in the real world, I despise it and go back to wanting a /48 distributed with my house, or at least, some way to buy one from my ISP. 4) In my case at least the prefix distribution problem aint' problem 'cause I just ship /128s everywhere I need 'em with AHCP. /me ducks Yes, distributing prefixes is needed. 5) To finally get to your own point, there is no need to poll at the protocol level, the daemons on the responsible routers need be aware of changes and push them. Ideally there is some level of authentication involved, particularly in changes pushed like forcibly retract this ipv6 prefix and use this one instead because my provider just changed me for no f-ing good reason) We've demonstrated that a protocol like AHCP can do that, (and nobody is suggesting that AHCP as currently defined is sufficient, it merely serves as a convenient counter-example to the embed-everything-in-the-routing protocol thread, that anybody can install and run, as it's been available in linux for 6+ years) 6) A well defined set of TLVs and actions for border discovery, nat detection in ipv4, and carrying dns, ntp, and other core services is needed no matter how they are distributed. 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. me, for example, am observing how src/dst routing works in the real world, and am trying to improve it, deal with bcp38 and vpn technolgies, etc. There is a lot of work to be done to defeat in detail all the existing problems, and I argue strongly for trying stuff, iterating, and trying more stuff, until a viable standard for these problem emerges... ... and that, is probably the basic beef I have in modifying an existing routing protocol. Solving configuration distribution and border discovery, and nat detection, and core service distribution - needs a design small, flexible, and rapidly iterate-able, and *separate*, for these problems. I certainly wish we could foresee all problems in advance; we obviously can't (two years on this thread running), something flexible and iterate-able is needed. ___ homenet mailing list homenet@ietf.org
Re: [homenet] Homenet protocol decisions
Despite the protests, I detect hints of top-downness in many of the messages on this thread. Yes, it's an easy mistake to make. You're right, we should be very vigilant about that. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Op 31 jan. 2014, om 20:25 heeft Ole Troan otr...@employees.org het volgende geschreven: 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. 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. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Op 31 jan. 2014, om 19:56 heeft Lorenzo Colitti lore...@google.com het volgende geschreven: On Fri, Jan 31, 2014 at 10:54 AM, Teco Boot t...@inf-net.nl wrote: And what happens when the routing protocol finds out that, even though the delegation protocol thinks everything is OK and addresses were delegated just fine, the network is now partitioned? How do you reassign addresses in that case? I don't see a problem. If the two partitions have border router(s), addresses for the prefixes for the connected border router keeps functioning. Prefixes for the disconnected border router(s) should be deprecated. Is is an internal function on the router, based on topology information and configured prefixes, provided by routing protocol and prefix distribution protocol. How do you tell the prefix assignment protocol that it needs to resolve addressing conflicts when you merge two networks that have the same prefixes? First we have to verify if this can happen. My favorite is using DHCP-PD with server on CPE (edge) box (and elected box for ULA). This box should circumvent your scenario. Er, *what*? You are aware that if you have a partition, one of the two partitions will not be able to reach the DHCP server? Does it matter? Prefixes for unreachable DHCP servers should be deprecated. Leases wil expire. A mobility tool is needed for connection survival (MPTCP, whatever). Yes, here is a need for coupled routing and prefix management. The routing table has state on connectivity to border routers. Prefix management makes use of that. Where is the need for coupled protocols? Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
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
Hi Ole, We need to decide, if we want prefix assignment and distribution of other configuration information integrated in a routing protocol. There's two orthogonal decisions. One is whether to make the configuration protocol a subprotocol of the routing protocol. (I have mentioned earlier that I very strongly favour a separate configuration protocol, I won't repeat my arguments here.) The other is to what extent other configuration information should be carried by the Homenet Configuration Protocol. The principled solution would be to mandate site-local multicast, and have application-layer protocols design their own discovery mechanisms (the end-to-end argument and all that). The pragmatic solution would be to include the kitchen sink in the configuration protocol. (My gut feeling is for an extensible configuration protocol that can carry arbitrary extra information, but that's simply because I don't have any experience with site-local multicast. I hope somebody can convince me that we can take site-local multicast for granted.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Juliusz, 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. I think that's a false assumption. It's derived from the old-style management of campus and enterprise networks, where there *is* a source of authority that also understands how to configure a network. That simply doesn't exist in a homenet, especially when we move away from the single-CPE flat network to the much more complex networks we expect in the future. I think we need a completely different approach. Just by chance, I happen to have one in mind. It's discussed for the case of carrier networks in http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02 I believe that exactly the same approach is needed for homenets. Regards Brian On 02/02/2014 14:29, Juliusz Chroboczek wrote: Hi Ole, We need to decide, if we want prefix assignment and distribution of other configuration information integrated in a routing protocol. There's two orthogonal decisions. One is whether to make the configuration protocol a subprotocol of the routing protocol. (I have mentioned earlier that I very strongly favour a separate configuration protocol, I won't repeat my arguments here.) The other is to what extent other configuration information should be carried by the Homenet Configuration Protocol. The principled solution would be to mandate site-local multicast, and have application-layer protocols design their own discovery mechanisms (the end-to-end argument and all that). The pragmatic solution would be to include the kitchen sink in the configuration protocol. (My gut feeling is for an extensible configuration protocol that can carry arbitrary extra information, but that's simply because I don't have any experience with site-local multicast. I hope somebody can convince me that we can take site-local multicast for granted.) -- 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] Homenet protocol decisions
On Thu, 30 Jan 2014, Lorenzo Colitti wrote: If the routing protocol and the prefix distribution protocol are separate, then they can end up with different ideas on what prefix is on a given link. That will lead to blackholing. I don't agree. I think a valid approach is to have a separate protocol set the address on an interface which is then picked up by the routing protocol and redistributed just like if it was manually configured. Routing protocol deamons normally don't set interface IP addresses, they carry de-facto information they get from other places and the only thing they update is the RIB/FIB in the machine. 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. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
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 plugplay, 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
On 31.1.2014, at 11.16, Ole Troan otr...@employees.org wrote:
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.
SD would be much more trivial to solve if we allowed host changes, or at least
would write about desired features there. E.g. no mDNS, just use DNS-SD[1] or
something equally clever, and then you would have really consistent database of
active services across the network that routers could share, or could have god
DNS server, or something else (dtath’s DHT perhaps).
3.1.2 doesn’t sound very promising on that front (or the hundreds of millions
of fruity logo compatible devices that mostly do mDNS and consider that all SD
they ever need; then again, wonder how many of them do IPv6, or more
specifically, non-linklocal IPv6).
Cheers,
-Markus
[1] with insecure dns-update (RFC2136) and allowing only updating records are
related pertain to your IP{v4,v6} address and some sort of expiration logic
based on your L2 presence it might work reasonably well?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Op 31 jan. 2014, om 09:56 heeft Ole Troan otr...@employees.org het volgende geschreven: 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 plugplay, 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. Teco cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
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 plugplay, 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
Speaking as an interested observer only... On 1/31/14 3:57 AM, Teco Boot wrote: +1 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. Yes, let's not forget BGP (but probably not for the reasons Teco mentions it). Many folks have expressed regrets over the years with the amount of extra baggage that has been added to BGP. Most of the time, the argument for adding this non-routing stuff is that the distribution model is the same. The results have been less than stellar, IMO. However, we have to consider that the rate of information update for reachability is not the same as the update rate for prefix delegation. Will the transport of that extra information lead to performance issues, incompatibility with other devices speaking the same protocol, or concerns over the security model needed for these two different functions? Just food for thought. Regards, Brian signature.asc Description: OpenPGP digital signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Teco Boot t...@inf-net.nl wrote: 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 plugplay, 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. Lest people worry about who is going to configure all of this, I want to point out that actually each of these protocols run in networks different security profiles. That is, the set of links running OSPF in Homenet are mostly equivalent security/trust-wise (taking into account that Fred and his wife will have tweaked things to live with their seperate corporate policies). The links running RPL are part of the Home *Automation* Network, and depending upon who is doing things, may be less or more trusted than the OSPF parts (probably, also depending upon your point of view). There will be routers/firewalls that speak Homenet/OSPF on one side and RPL on the other. Ditto for the OLSRv2/AODV/Babel adhoc running links: they are essentially alternative uplinks, which from the Homenet point of view are weird wall-free walled gardens. (Hanging gardens? http://en.wikipedia.org/wiki/Hanging_Gardens_of_Babylon note tower of babeld in the background) I've asked that we come to some decision about how we are going to make the protocol decision. It's been dragging on for over a year now. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpmJ4nm87P4A.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Le 30/01/2014 22:13, Lorenzo Colitti a écrit : On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan otr...@employees.org mailto:otr...@employees.org wrote: We need to decide, if we want prefix assignment and distribution of other configuration information integrated in a routing protocol. I think the two should be in the same protocol, because routing and addressing are tightly coupled. Fundamentally, there is no point in configuring an address on a host if the homenet doesn't have reachability to it - because you can't use that address to talk to anyone else in the homenet. (just a little point here, because I am encouraged by the beginning of the paragraph; yes, you can use a topologically incorrect address as src in outgoing packets, there are video stream applications for that; they work especially in the small setting of home, where there's no ingress filtering). If the routing protocol and the prefix distribution protocol are separate, then they can end up with different ideas on what prefix is on a given link. That will lead to blackholing. I tend to agree, modulo exception above. And provided I udnerstand the word 'blackholing'... Alex ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Le 31/01/2014 09:56, Ole Troan a écrit : 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 plugplay, I don't suggest to let configure grandma her favorite IGP ;) doesn't that mean we have to pick one? Yes, and here's my preferred: pick DHCP, it satisfies all requirements; where it doesnt update it. Then plug it into OSPF, then onto BGP. Alex 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] Homenet protocol decisions
Op 31 jan. 2014, om 18:13 heeft Lorenzo Colitti lore...@google.com het volgende geschreven: On Fri, Jan 31, 2014 at 12:37 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: If the routing protocol and the prefix distribution protocol are separate, then they can end up with different ideas on what prefix is on a given link. That will lead to blackholing. I don't agree. I think a valid approach is to have a separate protocol set the address on an interface which is then picked up by the routing protocol and redistributed just like if it was manually configured. And what happens when the routing protocol finds out that, even though the delegation protocol thinks everything is OK and addresses were delegated just fine, the network is now partitioned? How do you reassign addresses in that case? I don't see a problem. If the two partitions have border router(s), addresses for the prefixes for the connected border router keeps functioning. Prefixes for the disconnected border router(s) should be deprecated. Is is an internal function on the router, based on topology information and configured prefixes, provided by routing protocol and prefix distribution protocol. How do you tell the prefix assignment protocol that it needs to resolve addressing conflicts when you merge two networks that have the same prefixes? First we have to verify if this can happen. My favorite is using DHCP-PD with server on CPE (edge) box (and elected box for ULA). This box should circumvent your scenario. You have to tightly couple prefix assignment and routing again. In which case it's just better to have the same protocol. I can't follow your arguments. Routing protocol deamons normally don't set interface IP addresses, they carry de-facto information they get from other places and the only thing they update is the RIB/FIB in the machine. Yes, but in that case the responsibility for getting IP addresses correct and non-overlapping falls on the operator. A self-organizing network doesn't have an operator. I can't see how strongly coupled routing protocol and prefix distribution protocol can help. 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. That's different. The assumption at the service layer is that below it, the network will figure out routing and addressing, and packets either get to the destination or they don't. What you're talking about is to have two strongly coupled things in the networking layer (addressing and routing) be run by separate protocols. Yes, they are (strongly) related. That doesn't mean that they shall be processed by same protocol. Maybe better have two simple protocols, with minimal interaction. Both protocols will have their own life cycle. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
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
Hi, I am also interested in this direction. Thanks for the diagram, it illustrates well. 'Tightly couple routing protocol and prefix assignment, as well as distribution of other configuration information'? (yes/no) Yes. But, 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. For example, would coupling the DHCP-PD assignment operations triggering routing protocol updates mean tight or loose coupling. Or would this be a 100% alternative to a routing protocol-only prefix assignment solution? I am asking because I author an inidividual draft draft-petrescu-relay-route-pd-problem-00.txt Route Problem at Relay during DHCPv6 Prefix Delegation in this space. Alex Le 30/01/2014 11:48, Ole Troan a écrit : All, Updating the ospf prefix-assingment draft has been on my todo list for a long time. Before doing so I wanted to ask the working group if there was any clear direction evolving. Any views on the decisions in the flow chart attached? Anything I missed? To summarize: 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. 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] Homenet protocol decisions
On 30.1.2014, at 13.11, Alexandru Petrescu alexandru.petre...@gmail.com wrote: Le 30/01/2014 12:04, Ole Troan a écrit : 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? Given that it fulfills requirements, yes. I’m not aware of one, though. Off the cuff requirements follow: - ~distributed database across network (=every node acts on same information, at least with some delay; some pruning may be possible for some cases, but not much; for simplification I’d say same information everywhere) - precedence mechanism for sorting out conflicts among participating nodes - information about neighbors on local link(s) (and preferably also some precedence function for deciding e.g. who needs to do DHCPv4 server duties if supporting IPv4) Given node == router in this use case, it smells a lot like link state routing protocol to me. Has someone defined one without routing functionality as such? Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
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?
Alex
cheers,
Ole
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Le 30 janv. 2014 à 13:38, Alexandru Petrescu alexandru.petre...@gmail.com 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. How can it get addresses from both
prefixes ?
Cheers,
Pierre
Alex
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] Homenet protocol decisions
Pierre,
Thanks for the reply.
Le 30/01/2014 13:46, Pierre Pfister a écrit :
Le 30 janv. 2014 à 13:38, Alexandru Petrescu
alexandru.petre...@gmail.com 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
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
Re: [homenet] Homenet protocol decisions
Hi all, 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. 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 swm...@swm.pp.sewrote: 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
Re: [homenet] Homenet protocol decisions
On Thu, Jan 30, 2014 at 5:18 AM, Mikael Abrahamsson swm...@swm.pp.se 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 don't want it in the routing protocol. 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, I don't have any love for link-state personally. 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'm interested only in a routing protocol that works well with wired, wireless, and the internet of things. I don't think anyone will ever agree to a single routing protocol decision unless the protocol meets those requirements well, and is battle tested to meet those requirements well. And none do. 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. I was unenthusiastic, (as are the maintainers of every routing daemon I know of) and wanted to leverage ahcpd's methods (if not necessarily the existing version of the protocol) of propagating info, pre-routing information. 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? It is my hope that hybrid-proxy-mdns solves this. Certainly mdns is pretty good about picking up dynamically changed Topology discovery? Anything else? Anyhow, the src/dst enhancements for the IGP has to be done, I don't see much alternative to that. src/dst support landed in openwrt Barrier Breaker and cerowrt a week or two back. (it's still kind of rough). I also finally got up on comcast ipv6 personally. In addition to src/dst semi-solving a raft of problems (bcp38 for ipv6 anyone?), it exposed others like -1) Getting a swarm of RA's from upstream triggered a firewall reload every few seconds, which took a few seconds to reload, leading to an unusable ipv6 implementation. (if you are running cerowrt or openwrt on comcast DO upgrade. Ghu help you if you are merely on an ipv6 certified router) 0) comcast is only distributing a /60. It still seems that being able to distribute and route between /128s is needed, and nd proxying for folk that are only doing a /64 and have subnets. 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. 2) most vpn technologies are not aware of src/dst routing decisions and routing protocols can route around them, mistakenly. (tried strongswan so far) 3) Boy do we need to be able to forcibly retract ips and routes after a reboot and acquisition of a new subnet and loss of an old. The only way I can see clear to doing this is to support some form of authentication. I got this subnet from this source, and now it's telling me to retract it in favor of this subnet 4) the vast increase in ipv6 related multicast led me to finally violate the 802.11 standard and fix wireless multicast rates to 9mbits. So far that hasn't broken anything. Anyhow, I don't think DHCPv6-PD is a good method to assign prefixes to interfaces. Well, it works on the edge gateway, not so much on interior. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
On 30.1.2014, at 17.50, Dave Taht dave.t...@gmail.com wrote: don’t want it in the routing protocol. Why not? You can stick in kitchen sink there! ;-) 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'm interested only in a routing protocol that works well with wired, wireless, and the internet of things. I don't think anyone will ever agree to a single routing protocol decision unless the protocol meets those requirements well, and is battle tested to meet those requirements well. And none do. The definition of ‘works’ varies by people, so by that definition, I don’t think there is much to see here. 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? It is my hope that hybrid-proxy-mdns solves this. Certainly mdns is pretty good about picking up dynamically changed hybrid proxy fixes some things ( see https://github.com/sbyx/ohybridproxy for a minimalist implementation that seems to work, more or less ). However, it needs quite a bit of configuration on top of that that you can’t squeeze in easily; or at least, you wind up with either - configuration coming from some other protocol (like my old OSPF+SD draft), or - dns-updates + god DNS server + god DNS server replication within your home I’m not sure which is worse, but neither sounds very appealing. It still seems that being able to distribute and route between /128s is needed, and nd proxying for folk that are only doing a /64 and have subnets. Lots of nodes still don’t do stateful DHCPv6 (and even fewer do AHCP or something else); obviously, we could just ignore them and point at RFC6434? Hmm. 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. Does it really work without host changes? Let’s assume you have prefixes A and B from ISPs ISP_A, ISP_B. You have host that has addresses in A and B. It chooses to point it’s upstream resolver at your dnsmasq on your router. How do you figure which upstream DNS server to use? A and B source address won’t help in this case, as DNS resolution is done with ‘point SOMETHING at configured DNS server’ in most current hosts. 4) the vast increase in ipv6 related multicast led me to finally violate the 802.11 standard and fix wireless multicast rates to 9mbits. So far that hasn’t broken anything. Oho. Do you have concrete numbers on how much multicast you’re seeing in and what sort of topology? Just base IPv6 stuff or e.g. mdns? Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
On Thu, Jan 30, 2014 at 8:46 AM, Markus Stenberg markus.stenb...@iki.fi wrote: On 30.1.2014, at 17.50, Dave Taht dave.t...@gmail.com wrote: don't want it in the routing protocol. Why not? You can stick in kitchen sink there! ;-) 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'm interested only in a routing protocol that works well with wired, wireless, and the internet of things. I don't think anyone will ever agree to a single routing protocol decision unless the protocol meets those requirements well, and is battle tested to meet those requirements well. And none do. The definition of 'works' varies by people, so by that definition, I don't think there is much to see here. Much work is required here, and co-ordination with the wgs on internet of things would make sense. And running code, in upstream versions of the relevant daemons. 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? It is my hope that hybrid-proxy-mdns solves this. Certainly mdns is pretty good about picking up dynamically changed hybrid proxy fixes some things ( see https://github.com/sbyx/ohybridproxy for a minimalist implementation that seems to work, more or less ). However, it needs quite a bit of configuration on top of that that you can't squeeze in easily; or at least, you wind up with either - configuration coming from some other protocol (like my old OSPF+SD draft), or - dns-updates + god DNS server + god DNS server replication within your home I'm not sure which is worse, but neither sounds very appealing. Yep, we need a replacement for dns, that is replicable (uses a dht?), robust, and secure. Anyone? It still seems that being able to distribute and route between /128s is needed, and nd proxying for folk that are only doing a /64 and have subnets. Lots of nodes still don't do stateful DHCPv6 (and even fewer do AHCP or something else); obviously, we could just ignore them and point at RFC6434? Hmm. I don't mind pushing people at the standards at all :) I never grokked much of the overall emphasis on distributing /64s everywhere though. the problem I've long had to deal with is only getting a single /64 at best in a routed network (and /60 doesn't help much either). ahcp has and has been for 6 years on linux apt-get install babeld # pulls in ahcp edit /etc/default/ahcpd to add your interfaces and specify -6 only edit /etc/ahcp/ahcp-script.sh # to more sanely add servers walla. you get /128s. dhcpv6 is similar, of course. Presently openwrt is handing out /128s for stateful dhcpv6, I don't know if that's intended. 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. Does it really work without host changes? Let's assume you have prefixes A and B from ISPs ISP_A, yes. ISP_B. You have host that has addresses in A and B. It chooses to point it's upstream resolver at your dnsmasq on your router. How do you figure which upstream DNS server to use? A and B source address won't help in this case, as DNS resolution is done with 'point SOMETHING at configured DNS server' in most current hosts. in-home hosts can point to any local dns server over any ip address type, be it ipv4, link local, ula, or some set of ISP provided address. on the gateway the local dns server needs to distinguish from what ISP was derived the relevant source addresses, so it can issue queries to an upstream dns server, which involves abandoning leveraging /etc/resolv.conf.auto, for a dnsmasq specific configuration: cat /tmp/dnsmasq.d/comcast.conf server=2001:558:feed::1@260x:y:z::1 server=2001:558:feed::2@260x:y:z::1 Bind also can do the same, but the syntax is more involved. The in-home dns server also needs to ensure it only responds to queries from internal hosts (so as not to become a open resolver), presently that's done by ignoring queries from the external interface(s). It would be nice if queries from external hosts for the records for your in-home domain worked. Are there any dynamic dns providers working with s yet? incidentally one thing that could be used specifically for dns is to give the server it's own ipv6 address to play in, thus freeing up all ports to protect against things like the kaminsky attack, and better being able to correctly handle queries from the universe. Another option is run dns on a separate box, which conceptually hands the address awareness problem back to some sort of protocol. (Personally I see a lot of homes not running a local dns server and relying on mdns internally instead.) I was very happy to start routing all my dns traffic over ipv6
Re: [homenet] Homenet protocol decisions
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 swm...@swm.pp.se 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
Re: [homenet] Homenet protocol decisions
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
On 31/01/2014 10:53, Ole Troan wrote: 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 Well, it probably doesn't belong here, but we may need different first hops to reach different exit routers in the general case. However, yes, it's not needed as part of PD itself. Brian - 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
