Re: [homenet] 6renum redux [Routing protocol comparison document]
On Tue, 3 Mar 2015, Mark Andrews wrote: What we really should be telling ISPs is that renumber events should be make before break. There is zero reason other plain poor customer service to not do this. There are some markets in the world, where customers *demand* to be frequently renumbered, because they think this is a privacy measure. My current thinking in this area is to provide about 1 hour of address overlap to the home, where the old prefix is not preferred and the new is available for new connections. This would mean that most services would work just fine as long as they frequently (at least once per hour) re-establish their TCP session. Otherwise they have to do like mosh and try other connections when the first one breaks. I still think there needs to be quite a lot of work done on APIs and best common practices in order for applications to do the right thing so this kind of renumbering event works. Most likely it's going to require a FOSS library that will act as a middle layer between the application and the network so applications don't have to talk directly to the POSIX interfaces (which plain suck and haven't been updated in 15 years or so). We probably need a 5-10 (wo)man-year effort with a FOSS code outcome in order to get this done. I don't know who's interested in doing this. We have quite a lot of standards and documentation that can be used, what's lacking is actual code that the normal application developer can use, that is also multi-platform. Right now Microsoft, Apple and Google are putting a lot of effort into these APIs for Windows, OSX/iOS and Android respectively. We need this for the mainly Linux-driven FOSS universe (I don't know how much of the Android efforts are actually trickling back into regular Linux). I belive MP-TCP has a role to play here as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On Mar 2, 2015, at 7:32 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org Christian Hopps writes: Hi homenet-wg, One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? Thanks, Chris. Chris, Yes. I agree. And OSPF could do the same, without dragging CLNP in with it. Using CLNP framing for IS-IS packets at the L2 layer is not the same as dragging in CLNP. No homenet router is going to do anything with ISO like frames other than drop them or hand them off to IS-IS. Maybe ISIS-WG should consider an ISIS-over-IP draft? I actually presented that draft back in 1999, it was my first presentation at IETF; it didn’t go anywhere. :) Chris. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Mar 3, 2015, at 3:24 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: I still think there needs to be quite a lot of work done on APIs and best common practices in order for applications to do the right thing so this kind of renumbering event works. Most likely it's going to require a FOSS library that will act as a middle layer between the application and the network so applications don't have to talk directly to the POSIX interfaces (which plain suck and haven't been updated in 15 years or so). Why? The only case where it will matter is for long-lived connections that can't restart. So your overnight ssh, or your very long download. Any other use will survive the renumbering event because you gave an hour's notice. Deprecated addresses already shouldn't be selected for new connections by the stack--there's no need to modify the application. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Mar 3, 2015, at 8:57 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: This is probably the use case we most care about. I think it's actually a strong argument for going with a longer deprecation period. E.g., if your deprecation period were three hours, we simply wouldn't have a problem. I don't agree with this at all. I can easily come up with an equivalent scenario that would require an even longer overlap in time, for instance a long video conferencing session, and also there are longer movies than 3 hours. To be clear, I don't mean that we shouldn't try to improve the situation with renumbering, and I am curious to see the results of your survey. I'm just saying that we also have to accept that change doesn't always happen immediately, and it's worth taking interim steps to avoid breaking existing protocols in obvious ways while also pursuing a long-term strategy of fixing the protocols so that they don't break. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Tue, 3 Mar 2015, Michael Sweet wrote: True, but most video conferencing software and live video feeds handle disconnects gracefully (enough) already, and most streaming video is not done using a single file/URL but with a series of files/URLs, with each file/URL representing a chapter or other divisible unit within the program/movie being watched - there you will either seamlessly transition to the new address when the next chapter is fetched, or the application will detect the lost connection/stalled data and then attempt a reconnect which gets the new address. So don't assume there will be problems when a network is renumbered - a lot of the work that's been done to deal with unreliable networks is equally useful for network changes, so long as the client application does not assume the network address of a named service won't change. So where is the sweet spot? 10 minutes? 30 minutes? 1 hour? 3 hour? 6 hour? 12 hour? I just tried this. I was on the same subnet on wired ethernet and on wifi (etablished the call on wired with disabled wifi, enabled wifi, waited 30 seconds, then unplugged wired) using my OSX macbook, using Skype voice session with another skype user, and it took around 10 seconds to detect the outage, and another 20 seconds to re-establish the call. I tried the same procedure with Facetime audio, and it disconnected the call after 10 seconds and didn't try to establish it again until I manually did something. Mosh fixes this with a 1-2 second outage. I have no reason to believe the above behavior would be different if the call was over IPv6 (which I presume it wasn't) and the address went away because of a renumbering event. So I'd say that at least two of the top VoIP clients on the market have no functionality to gracefully (30 second customer outage isn't gracefully) handling moving between two addresses. So applications need to get a *lot* better at being endpoint address independent. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 05:55 AM, David Oran wrote: On Mar 2, 2015, at 9:05 PM, Michael Thomas m...@mtcc.com wrote: On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says Hi, I'm your friendly homenet router and here's my public key. so you're mollified if somebody's cert says hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx instead? Actually, I’m suspicious, which is entirely appropriate. If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key. Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are really, really low. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
Mikael, On Mar 3, 2015, at 8:57 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Tue, 3 Mar 2015, Ted Lemon wrote: This is probably the use case we most care about. I think it's actually a strong argument for going with a longer deprecation period. E.g., if your deprecation period were three hours, we simply wouldn't have a problem. I don't agree with this at all. I can easily come up with an equivalent scenario that would require an even longer overlap in time, for instance a long video conferencing session, and also there are longer movies than 3 hours. True, but most video conferencing software and live video feeds handle disconnects gracefully (enough) already, and most streaming video is not done using a single file/URL but with a series of files/URLs, with each file/URL representing a chapter or other divisible unit within the program/movie being watched - there you will either seamlessly transition to the new address when the next chapter is fetched, or the application will detect the lost connection/stalled data and then attempt a reconnect which gets the new address. So don't assume there will be problems when a network is renumbered - a lot of the work that's been done to deal with unreliable networks is equally useful for network changes, so long as the client application does not assume the network address of a named service won't change. _ Michael Sweet, Senior Printing System Engineer, PWG Chair ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
Mikael, On Mar 3, 2015, at 10:34 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: ... So where is the sweet spot? 10 minutes? 30 minutes? 1 hour? 3 hour? 6 hour? 12 hour? My guess is around 1 hour, but clearly that is something that should be tested to verify (and ideally be configurable). I just tried this. I was on the same subnet on wired ethernet and on wifi (etablished the call on wired with disabled wifi, enabled wifi, waited 30 seconds, then unplugged wired) using my OSX macbook, using Skype voice session with another skype user, and it took around 10 seconds to detect the outage, and another 20 seconds to re-establish the call. 30 seconds is not a huge amount of time, and certainly that could be improved, but it doesn't point to a need for or that it would be useful to make massive changes to the core networking APIs... I tried the same procedure with Facetime audio, and it disconnected the call after 10 seconds and didn't try to establish it again until I manually did something. I think FaceTime audio doesn't reconnect while FaceTime video does, but I'm not connected to the team that does that software so I'm not 100% sure... Regardless, that is just a marketing/HI decision, not a technical one. Mosh fixes this with a 1-2 second outage. Good for Mosh. I have no reason to believe the above behavior would be different if the call was over IPv6 (which I presume it wasn't) and the address went away because of a renumbering event. I agree. So I'd say that at least two of the top VoIP clients on the market have no functionality to gracefully (30 second customer outage isn't gracefully) handling moving between two addresses. So applications need to get a *lot* better at being endpoint address independent. Need is a strong word - certainly they do not meet your high expectations, and there is likely room for improvement, but what works for Mosh and the recovery times it has may not be reflective of what other protocols can do. _ Michael Sweet, Senior Printing System Engineer, PWG Chair ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On 3.3.2015, at 18.04, Michael Sweet msw...@apple.com wrote: I just tried this. I was on the same subnet on wired ethernet and on wifi (etablished the call on wired with disabled wifi, enabled wifi, waited 30 seconds, then unplugged wired) using my OSX macbook, using Skype voice session with another skype user, and it took around 10 seconds to detect the outage, and another 20 seconds to re-establish the call. 30 seconds is not a huge amount of time, and certainly that could be improved, but it doesn’t point to a need for or that it would be useful to make massive changes to the core networking APIs... If my phone call breaks for 30 seconds, I will cut the call, curse phone operator to deepest pit of hell, try to recall, fail, and perhaps iterate this 2-3 times during the 30 seconds. I am not sure why this would be acceptable on IP based service. I tried the same procedure with Facetime audio, and it disconnected the call after 10 seconds and didn't try to establish it again until I manually did something. I think FaceTime audio doesn't reconnect while FaceTime video does, but I'm not connected to the team that does that software so I'm not 100% sure... Regardless, that is just a marketing/HI decision, not a technical one. Sounds very strange if marketing/HI makes technical decisions that should not be visible to the user (except in the negative case like this one). That explains why my Mac Pro behaves so badly though. Mosh fixes this with a 1-2 second outage. Good for Mosh. I am even more curious about mp-mosh[1], is there any outage with it at all? Cheers, -Markus [1] https://github.com/boutier/mosh ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
Mikael Abrahamsson wrote: On Tue, 3 Mar 2015, Michael Sweet wrote: True, but most video conferencing software and live video feeds handle disconnects gracefully (enough) already, and most streaming video is not done using a single file/URL but with a series of files/URLs, with each file/URL representing a chapter or other divisible unit within the program/movie being watched - there you will either seamlessly transition to the new address when the next chapter is fetched, or the application will detect the lost connection/stalled data and then attempt a reconnect which gets the new address. So don't assume there will be problems when a network is renumbered - a lot of the work that's been done to deal with unreliable networks is equally useful for network changes, so long as the client application does not assume the network address of a named service won't change. So where is the sweet spot? 10 minutes? 30 minutes? 1 hour? 3 hour? 6 hour? 12 hour? I just tried this. I was on the same subnet on wired ethernet and on wifi (etablished the call on wired with disabled wifi, enabled wifi, waited 30 seconds, then unplugged wired) using my OSX macbook, using Skype voice session with another skype user, and it took around 10 seconds to detect the outage, and another 20 seconds to re-establish the call. I tried the same procedure with Facetime audio, and it disconnected the call after 10 seconds and didn't try to establish it again until I manually did something. Mosh fixes this with a 1-2 second outage. I have no reason to believe the above behavior would be different if the call was over IPv6 (which I presume it wasn't) and the address went away because of a renumbering event. So I'd say that at least two of the top VoIP clients on the market have no functionality to gracefully (30 second customer outage isn't gracefully) handling moving between two addresses. So applications need to get a *lot* better at being endpoint address independent. I read your requirements. I think there are two completely separate mechanisms being discussed here: the need for rapid failover to a previously known alternative address for your partner device, and discovering the alternative addresses of your partner. The one thing I think that is still missing in the discussion is caching in the name space. Whether name resolution of the remote partner address be done via mDNS, DNS, or monitoring the currently established channel between partner nodes like in shim6, whatever. I / we know from experience with Appletalk II NBP and ZIP that 100% dynamic a la minute server/name - address resolution doesn't scale well, and certainly not beyond enterprise level. So we know we have to have some sort of caching in the name space. Or the list of partner addresses at the other end of the channel. Whatever. You cannot poll your partner on MOSH every 1mSec to see if it has changed its addresses. I think caching in the name/address space sets a much more relevant lower limit on the speed of renumbering/ roaming via L3 on wifi/ whatever other event that causes your host's address(es) to change. Otherwise you're forced into either taking your L3 prefix with you and using routing to the end host, or NATting the old address, or using rendezvous points, or being able to deprecate cache contents. None of which have proven particularly practicable. So your 1 hour flash renumbering event seems way too small IMHO. 36 hours would seem more reasonable. I think that time limit is completely independent of a node's ability to fallback/fall forward to previously known alternative addresses (mSec range). And for the wifi roaming example: if a node already knew all of the wifi prefixes in use in a Homenet, it could publish records well in advance of any move for all possible interfaces it could attach to. -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are really, really low. You might want to entertain you reading draft-behringer-homenet-trust-bootstrap which gives a good idea how this could work (the general ideas, maybe not the specific implementation). Of course the normal end user is not going to ever look at or manually generate a certificate. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Tue, 3 Mar 2015, Ted Lemon wrote: Why? The only case where it will matter is for long-lived connections that can't restart. So your overnight ssh, or your very long download. Any other use will survive the renumbering event because you gave an hour's notice. Deprecated addresses already shouldn't be selected for new connections by the stack--there's no need to modify the application. Yes, but I want to make sure also these long lived connections can survive the renumbering event. I use mosh which gives me this for my ssh. I have completely stopped using TCP for ssh, because it just sucks. Right now I connect to a wifi and before I can basically switch to my terminal application, mosh has already reconnected. This is how I want things to work. I can imagine a stream video application that uses a single TCP session, and watching a movie over this can easily take more than an hour. I need to check, but I would imagine for instance xbmc accessing a http(s) based file server would just use a single TCP session for the entire session. I can verify this if it's of interest. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Mar 3, 2015, at 8:20 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: I can imagine a stream video application that uses a single TCP session, and watching a movie over this can easily take more than an hour. I need to check, but I would imagine for instance xbmc accessing a http(s) based file server would just use a single TCP session for the entire session. I can verify this if it's of interest. This is probably the use case we most care about. I think it's actually a strong argument for going with a longer deprecation period. E.g., if your deprecation period were three hours, we simply wouldn't have a problem. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] MPVD requirments in homenet
Hi Ole, By saying multiple services I mean the services (i.e. Basic internet, VoIP, VoD...) that can be generally provisioned independently from each other, not necessarily from a single provider. Best wishes, Liang -邮件原件- 发件人: homenet [mailto:homenet-boun...@ietf.org] 代表 Ole Troan 发送时间: 2015年3月3日 22:05 收件人: Liang Geng 抄送: homenet@ietf.org; Hui Deng 主题: Re: [homenet] MPVD requirments in homenet Liang, what do you mean by multiple services? if you mean walled garden, the homenet architecture only has the following to say: It should be noted that some multihoming scenarios may see one upstream being a walled garden and thus only appropriate for connectivity to the services of that provider; an example may be a VPN service that only routes back to the enterprise business network of a user in the homenet. As per Section 4.2.1 of [RFC3002], we do not specifically target walled-garden multihoming as a goal of this document. cheers, Ole On 03 Mar 2015, at 10:30 , Liang Geng liang.g...@hotmail.com wrote: Hi all, I'm Liang from China Mobile, a recent follower of this community. Following a previous thread concerning the discussion of MPVD in Homenet on 3rd Feb, I personally think that certain use cases are quite well in line with the mif MPVD scenario. As homenet architecture provides autonomic network configuration in future multi-service, multi-homed environment, I think it is also a new challenge in terms of CPE management. My immature thought would be that MPvD may provide a promising model. May I propose the following problems for the list to see if it is worthy of some serious investigation, on which hopefully would be something interesting I could make a brief draft for further discussion (maybe in Dallas meeting)? Problems to be addressed 1. Use case of MPVD in homenet -Single ISP, multiple services (covers single/multiple CE router(s)) -Multiple ISP, multiple services (covers single/multiple CE router(s)) 2. The association of PvD and network configuration in homenet -Address configuration -Naming and service discovery For both, now thinking of a new PvD TLV which enables the association of certain configuration and PvD. Initial thought would be that no DHCP option extension is needed terms of HNCP based pvd coveying. Host and non-HNCP routers may refer to mif work on how pvd information is provided. ...more to be discussed and added Any comments would be extremely welcome. Best wishes Liang ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00
On Mon, 2 Mar 2015, Ole Troan wrote: typically the ISP router snoops DHCPv6 messages and does route injection based on that, or the DHCPv6 server runs on the ISP router and does route injection based on binding state. So this is a plausible way of doing intra-home mobility of prefixes. Unfortunately it relies on IA_NA which not all devices will use. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Tue, 3 Mar 2015, Ray Hunter wrote: I think there are two completely separate mechanisms being discussed here: the need for rapid failover to a previously known alternative address for your partner device, and discovering the alternative addresses of your partner. Agree. The one thing I think that is still missing in the discussion is caching in the name space. Whether name resolution of the remote partner address be done via mDNS, DNS, or monitoring the currently established channel between partner nodes like in shim6, whatever. I think we need this done via the existing channel, a la MP-TCP and SHIM6. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your normal authentication scheme. Obviously, would be nice if protocol supported certs directly, but it’s not required. IKE provides just symmetric crypto key between two parties. Typical network has more (and routing protocols use multicast). Multiparty IKE is more or less dead (or undead?). Remember, we need whole network to agree on the keys, or at least everyone on the link if any multicast is used in a way that requires authentication or confidentiality. (HNCP is designed to avoid transmitting anything important over multicast; are routing protocols? For most part, I think not.) Sorry, I haven't been following all this discussion so I may be missing something, but ... I would say: Pick a master (on a link, or the entire network); master calculates a random key; distributes it to the other nodes using asymmetric crypto; all nodes use that key. For rollover use some key chain mechanism such that for a period of time old and new key are accepted. Plug those keys into the normal routing protocol security mechanism. What am I missing? Michael ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: The basis for the metric in RFC 7181 is out of scope. So what did you use? This: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04 I am still using the multicast loss (plus the raw link speed) to judge the links, but I have done some early experiments with integrating the L2 frame statistics too. Not sure it works that well for wifi without a lot of probing, much more than you need for getting an useful link speed). Also I'm not sure what you meant by the MPR code. Did you leave in the LINK_METRIC TLV and leave out the rest of RFC 7181? Multipoint Relays. Its a method to reduce the flooding overhead in a wireless mesh network. Its defined in RFC 7181, but its a modification of NHDP so I put it into my NHDP implementation. So my point still stands that there is nothing like LQM is anything over WiFi (more correctly 802.11). With an Atheros card I get both transmitted frames, retransmitted frames and (completely) lost frames on the sender side of a link... its just that these values are not that useful when most of your wireless links are not transporting traffic. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
Regards Brian Carpenter http://orcid.org/-0001-7924-6182 On 04/03/2015 05:54, Mikael Abrahamsson wrote: On Tue, 3 Mar 2015, Ray Hunter wrote: I think there are two completely separate mechanisms being discussed here: the need for rapid failover to a previously known alternative address for your partner device, and discovering the alternative addresses of your partner. Agree. The one thing I think that is still missing in the discussion is caching in the name space. Whether name resolution of the remote partner address be done via mDNS, DNS, or monitoring the currently established channel between partner nodes like in shim6, whatever. I think we need this done via the existing channel, a la MP-TCP and SHIM6. Much as I love shim6, it's currently a broken solution because most firewalls drop packets with shim6 extension headers. And it requires both hosts to be updated to be effective. Much as I love MPTCP, it only helps TCP sessions. And it requires both hosts to be updated to be effective. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message CAGnRvuqcwFjE6NZ_tOnQEBN8RG8wUFeSsQSqsETh=acpw_v...@mail.gmail.com Henning Rogge writes: Sorry, too much working on the implementation side of NHDP/OLSRv2 in the last years... should have thought a bit more about the reply before sending it. Yes, you are correct that RFC6130 does not contain the description of the link metric... it only contains a rough EWMA based link quality hysteresis that switches on and of links. I don't even think the algorithm defined in the RFC is really useful (but its easy to plug in a different one because the Link Quality calculation and decision is just local). I was thinking about the Link Metric NHDP extension defined in RFC7181 (which can easily be used without using the OLSRv2 routing), which is based on Incoming/Outgoing Link Metric values. (in my implementation I put the whole Link Metric and MPR code into NHDP to make them usable without OLSRv2) Henning Rogge The basis for the metric in RFC 7181 is out of scope. So what did you use? Also I'm not sure what you meant by the MPR code. Did you leave in the LINK_METRIC TLV and leave out the rest of RFC 7181? So my point still stands that there is nothing like LQM is anything over WiFi (more correctly 802.11). Curtis On Tue, Mar 3, 2015 at 12:28 AM, Curtis Villamizar cur...@ipv6.occnc.com wrote: Henning, You cut the following off the top of your reply. The Neighborhood Discovery Protocol (RFC 6130) has a similar mechanism... each node collects local link quality information and then shares them from time to time with all neighbors, which means everyone knows about both directions of a link. Henning Rogge RFC 6130 uses probes (hello message success rate). Cutting this off makes a big difference. See below. In message CAGnRvup-F4_A1-sHkh3EWRgrX=iuthbdmjzz+xk_g+7bm+e...@mail.gmail.com Henning Rogge writes: On Sun, Mar 1, 2015 at 11:14 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: RFC 6130 uses probes (hello message success rate). No, it does not... at least not for calculating the link metric. The discussion was the quality measurement. The quality measurement uses hello message success rate. See section 14 in RFC 6130. The discussion was not link metrics. You chopped the prior discussion when quoting the one sentence above. Below I describe the why RFC 6130 Link Quality is nothing like LQM. For example: If an AP sends 100 packets a second to a neightbor and 5 drop it would be better to send one LQM packet and know that loss is 5% rather than have to send 100 hello packets in addition to the 100 data packets to reliably know that loss is 5%. (In MPLS it could be a billion packets between LM packets). LQM does not rely on a count of probe packet success. Please reread what I sent earlier or read about PPP LQM or MPLS-TP LM OAM. Please compare RFC 6130 section 14.2 (Basic Principles of Link Quality) Link quality and Link metric are two different kind of things for NHDP/OLSRv2. Link quality is used for a hysteresis mechanism that can make a link symmetric/asymmetric. Link metric (as defined in RFC 7181) is used for path selection. with RFC 1989 and RFC 6375. In RFC 6375 look at Section 2.2 (Packet Loss Measurement) and Section 3.1 (Loss Measurement Message Format). RFC 6130 has no comparable mechanism. RFC6130 (NHDP) and RFC 7181 (OLSRv2) define the incoming link METRIC calculation as an external process. It can be anything, as long as it gives you a dimensional link cost in the right range. I admit the splitup between RFC6130 and RFC7181 is a bit confusing... Henning Rogge I know the difference between link quality and link metric. You just jumped from ND to OLSRv2 for MANET. RFC 7181 does not preclude using a LQM-like mechanism, but neither RFC 6130 or RFC 7181 define such a mechanism. The discussion was regarding doing something like LQM and three messages ago you stated that RFC 6130 already had something like LQM. Neither RFC 6130 or RFC 7181 define a mechanism anything like LQM. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Mar 3, 2015, at 11:42 AM, Ray Hunter v6...@globis.net wrote: I think caching in the name/address space sets a much more relevant lower limit on the speed of renumbering/ roaming via L3 on wifi/ whatever other event that causes your host's address(es) to change. Otherwise you're forced into either taking your L3 prefix with you and using routing to the end host, or NATting the old address, or using rendezvous points, or being able to deprecate cache contents. None of which have proven particularly practicable. So your 1 hour flash renumbering event seems way too small IMHO. 36 hours would see Why do you say that? Is a ~60 minute TTL too short for a home device? I don't think so. As soon as the old address is deprecated, you remove the record pointing to it--you don't keep it around. You install records only for non-deprecated addresses. Why is this a problem? Why the need for a 36 hour timeframe? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00
Ole Troan otr...@employees.org wrote: I was planning on using ISC DHCP 4.3.1 together with an external script as described in https://github.com/mpalmer/isc-dhcp contrib, to detect the next hop address of my homenet router and install the relevant route for the delegated prefix on the last-hop ISP router (a Linux box). typically the ISP router snoops DHCPv6 messages and does route injection based on that, or the DHCPv6 server runs on the ISP router and does route injection based on binding state. The IPv6 support in ServPOET's PPPoE BMS (which I wrote last year) runs a DHCPv6 daemon on the router itself, and simply adds a route via the PPP link when the DHCPv6-PD occurs. The selection of prefix comes from radius during the PPP negotiation/authentication, and is passed laterally from the PPP process to the DHCPv6 process (which is called rfc6204d, because 7208 wasn't quite out at the time). The amount of DHCPv6 processing required for a PPP link is remarkably small, and I worry that I may have done too little. Of the three CPEs that I've tested with, one is OpenWRT BB (thanks to Stephen and Markus and the rest of the crew) and worked great, a second locked up tight when given an IPv6 PD, a third proclaimed IPv6 suport on the box, but had nothing inside. I have two more devices to test with: one of which requires translation from chinese, and the fifth I got last week, and I haven't powered on yet. (Thanks Hui!) I've been talking on and off with Tim Winters of the UNH interop lab, and at this point it seems that they just aren't equipped with IPv6 capable CPEs that do PPP such that visiting there makes sense. There are some there that do cable/ethernet-WAN, but not PPPoE WAN. (also m...@finepoint.com two days/week) -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message CAGnRvuq+kq+djqPvKHDXBdDkbfjt=gnj0owqvc241vllwxb...@mail.gmail.com Henning Rogge writes: On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: The basis for the metric in RFC 7181 is out of scope. So what did you use? This: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04 It seems like with this draft, packet with RFC 5444 (Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format) sequence numbers are counted and absent any of those, only HELLO packets are counted. If all packets had RFC 5444 sequence numbers this would have the same effect as LQM. Unfortunately this requires the host to use RFC 5444 encapsulation over WiFi. Unfortunately LQM requires both side to play. On the bright side, a host would only need to copy counters into a packet to allow the AP to gather information. I am still using the multicast loss (plus the raw link speed) to judge the links, but I have done some early experiments with integrating the L2 frame statistics too. Not sure it works that well for wifi without a lot of probing, much more than you need for getting an useful link speed). It would be nice to write down somewhere (preferably and internet-draft for WG purposes) exactly what you end up with once you've made good progress on this. Also I'm not sure what you meant by the MPR code. Did you leave in the LINK_METRIC TLV and leave out the rest of RFC 7181? Multipoint Relays. Its a method to reduce the flooding overhead in a wireless mesh network. Its defined in RFC 7181, but its a modification of NHDP so I put it into my NHDP implementation. So my point still stands that there is nothing like LQM is anything over WiFi (more correctly 802.11). With an Atheros card I get both transmitted frames, retransmitted frames and (completely) lost frames on the sender side of a link... its just that these values are not that useful when most of your wireless links are not transporting traffic. Henning Rogge Its great that you are working on wireless mesh networks. IMHO the typical homenet environment is Ethernet plus WiFi in AP mode, not mesh. Its good to have things that work well for mesh. Right now it would be really good to have solutions for the problem of lots of AP in a confined area. In some cases, such as appartment buildings with lots of consumer run AP, the issue is keeping the density of AP from congesting airwaves. In other cases (such as IETF, or an enterprise with lots of APs) hosts will be roaming among APs and that should be smoother than it is now. Unfortunately I don't think that is fixable with zero host changes. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
Ted Lemon mailto:mel...@fugue.com 3 March 2015 20:36 Why do you say that? Is a ~60 minute TTL too short for a home device? I don't think so. As soon as the old address is deprecated, you remove the record pointing to it--you don't keep it around. You install records only for non-deprecated addresses. Why is this a problem? Why the need for a 36 hour timeframe?24 ho 36 hours is a number plucked out of thin air by me that is longer than 24 hours, which is a historic default refresh time for many DNS servers e.g. RFC1912 https://www.ripe.net/ripe/docs/ripe-203 . One hour TTL could mean 24 times the DNS traffic compared to that historic norm. It also could mean (re)signing DNSSEC zones more than 24 times per day as hosts move around the homenet... So it's clearly a trade off. What's the difference in practical terms between 1 second, 1 minute, 1 hour, and 1 day? You either have more name resolution traffic (every day), or you have more temporary addresses and old prefixes hanging around for longer (during a renumbering event, which is presumably not every day). Any operators got any input on how often they propose to rotate prefixes on domestic connections? -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
In message alpine.deb.2.02.1503030917420.20...@uplift.swm.pp.se, Mikael Abrah amsson writes: On Tue, 3 Mar 2015, Mark Andrews wrote: What we really should be telling ISPs is that renumber events should be make before break. There is zero reason other plain poor customer service to not do this. There are some markets in the world, where customers *demand* to be frequently renumbered, because they think this is a privacy measure. And their long running TCP sessions break in IPv4. This doesn't mean that they can't do better with IPv6. We could also extend the temporary / permanent address model to PD. You get two prefixes from the ISP. One is designed to servers and other things that need long term stability. One is designed for ephemeral use. The application chooses which to use like they do today. My current thinking in this area is to provide about 1 hour of address overlap to the home, where the old prefix is not preferred and the new is available for new connections. This would mean that most services would work just fine as long as they frequently (at least once per hour) re-establish their TCP session. Otherwise they have to do like mosh and try other connections when the first one breaks. I still think there needs to be quite a lot of work done on APIs and best common practices in order for applications to do the right thing so this kind of renumbering event works. Most likely it's going to require a FOSS library that will act as a middle layer between the application and the network so applications don't have to talk directly to the POSIX interfaces (which plain suck and haven't been updated in 15 years or so). We probably need a 5-10 (wo)man-year effort with a FOSS code outcome in order to get this done. I don't know who's interested in doing this. We have quite a lot of standards and documentation that can be used, what's lacking is actual code that the normal application developer can use, that is also multi-platform. Right now Microsoft, Apple and Google are putting a lot of effort into these APIs for Windows, OSX/iOS and Android respectively. We need this for the mainly Linux-driven FOSS universe (I don't know how much of the Android efforts are actually trickling back into regular Linux). I belive MP-TCP has a role to play here as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
In message 54f611a6.2000...@gmail.com, Brian E Carpenter writes: Regards Brian Carpenter http://orcid.org/-0001-7924-6182 On 04/03/2015 05:54, Mikael Abrahamsson wrote: On Tue, 3 Mar 2015, Ray Hunter wrote: I think there are two completely separate mechanisms being discussed here: the need for rapid failover to a previously known alternative address for your partner device, and discovering the alternative addresses of your partner. Agree. The one thing I think that is still missing in the discussion is caching in the name space. Whether name resolution of the remote partner address be done via mDNS, DNS, or monitoring the currently established channel between partner nodes like in shim6, whatever. I think we need this done via the existing channel, a la MP-TCP and SHIM6. Much as I love shim6, it's currently a broken solution because most firewalls drop packets with shim6 extension headers. And it requires both hosts to be updated to be effective. Which requires the two ends that want to use shim6 to upgrade their firewalls. It isn't impossible to use shim6. If people had stopped complaining and started developing firewalls that handled options better we would be able to deploy them at the moment. It isn't impossible to do this at wire speed. Much as I love MPTCP, it only helps TCP sessions. And it requires both hosts to be updated to be effective. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
In message 54f62dda.9020...@globis.net, Ray Hunter writes: Ted Lemon mailto:mel...@fugue.com 3 March 2015 20:36 Why do you say that? Is a ~60 minute TTL too short for a home device? I don't think so. As soon as the old address is deprecated, you remove the record pointing to it--you don't keep it around. You install records only for non-deprecated addresses. Why is this a problem? Why the need for a 36 hour timeframe?24 ho 36 hours is a number plucked out of thin air by me that is longer than 24 hours, which is a historic default refresh time for many DNS servers e.g. RFC1912 https://www.ripe.net/ripe/docs/ripe-203 . One hour TTL could mean 24 times the DNS traffic compared to that historic norm. It also could mean (re)signing DNSSEC zones more than 24 times per day as hosts move around the homenet... TTLs and signature validity intervals are independent of each other. You can have a TTL of zero with a signature validity interval of 30 days. So it's clearly a trade off. The trade off is how often the data being signed changes. Dynamic zones only sign the data that is changing. If you update a A record that is two sets of signatures. Those for the A record set and the SOA record. You don't re-sign the entire zone unless you are crazy. Even doing it by hand the tools can work out what needs to be signed, re-signed and what doesn't. What's the difference in practical terms between 1 second, 1 minute, 1 hour, and 1 day? You either have more name resolution traffic (every day), or you have more temporary addresses and old prefixes hanging around for longer (during a renumbering event, which is presumably not every day). Any operators got any input on how often they propose to rotate prefixes on domestic connections? -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Wed, 4 Mar 2015, Mark Andrews wrote: We could also extend the temporary / permanent address model to PD. You get two prefixes from the ISP. One is designed to servers and other things that need long term stability. One is designed for ephemeral use. The application chooses which to use like they do today. Wait, isn't this already supported in PD? I thought it was. A device can request multiple PD already, correct? Or you mean you want to explicitly signal the difference between the two PDs, basically saying this PD will not get renewed, you should ask for an additional one? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Tue, 3 Mar 2015, Juliusz Chroboczek wrote: I still think there needs to be quite a lot of work done on APIs and best common practices in order for applications to do the right thing so this kind of renumbering event works. Most likely it's going to require a FOSS library that will act as a middle layer between the application and the network What are the applications that you think would benefit from that? UDP-based applications, mind you, since MP-TCP works marvelously for TCP. EVERYTHING that is not using TCP. Which is a lot. I don't want sessions that last more than a few seconds to rely on the address, anywhere. I think getting thoroughly acquainted with previous art is necessary. I'm sure there are other UDP-based applications than just Mosh and µTP-based BitTorrent that can deal with changing addresses, and we don't want to build something that's either too general, not general enough, or even both at the same time. That's why I said 5-10 man-year effort. I don't know on what level to solve this best. Since it requires some kind of authentication, perhaps it should be done by in a similar fashion to IPSEC but be done on a per-session basis, not per-IP. Also, TCP is hindered by often being included in the operating system and not under the application developer control at all. This is fine for most applications, but the larger ones with special needs might want to do something differently. Looking at for example QUIC, they went down the UDP route to fix this problem. So what I envision is a standardised protocol that could be implemented as a library on the host, be cross-plattform, probably run over UDP (at least short term), and combine some of the functionality of IPSEC and SHIM6 to enable authentication, encryption and address independence. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
Ted Lemon mailto:mel...@fugue.com 4 March 2015 03:21 On Mar 3, 2015, at 4:55 PM, Ray Hunterv6...@globis.net wrote: One hour TTL could mean 24 times the DNS traffic compared to that historic norm. It also could mean (re)signing DNSSEC zones more than 24 times per day as hosts move around the homenet... Caching is really only interesting for query clusters and frequently accessed domains. I don't think there is any reason to expect that there will be performance issues for homenet names, which I would expect would be infrequently accessed by relatively few resolvers. If I'm following draft-ietf-homenet-front-end-naming-delegation, then the hidden master is also located within the Homenet. Doesn't that mean that the (hidden master) DNS server itself also has to be renumbered? And the new content synched with the slave servers (outside of homenet) in a timely manner, before the old prefixes are expired? Are the values suggested in section 4.2 for SOA appropriate then? I understood a zone transfer was only triggered when the SOA contents changed, and that was only checked once the slave refresh timer had expired. You either have more name resolution traffic (every day), or you have more temporary addresses and old prefixes hanging around for longer (during a renumbering event, which is presumably not every day). Temporary addresses don't belong in the DNS. Stale information doesn't belong in the DNS. This seems like a no-brainer to me. -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
In message 54f6aace.3030...@globis.net, Ray Hunter writes: Ted Lemon mailto:mel...@fugue.com 4 March 2015 03:21 On Mar 3, 2015, at 4:55 PM, Ray Hunterv6...@globis.net wrote: One hour TTL could mean 24 times the DNS traffic compared to that historic norm. It also could mean (re)signing DNSSEC zones more than 24 times per day as hosts move around the homenet... Caching is really only interesting for query clusters and frequently access ed domains. I don't think there is any reason to expect that there will be performance issues for homenet names, which I would expect would be infrequen tly accessed by relatively few resolvers. If I'm following draft-ietf-homenet-front-end-naming-delegation, then the hidden master is also located within the Homenet. Doesn't that mean that the (hidden master) DNS server itself also has to be renumbered? And the new content synched with the slave servers (outside of homenet) in a timely manner, before the old prefixes are expired? Are the values suggested in section 4.2 for SOA appropriate then? I understood a zone transfer was only triggered when the SOA contents changed, and that was only checked once the slave refresh timer had expired. Zone transfers on SOA timer expiry very rarely happen these days. NOTIFY messages are the usual trigger. You either have more name resolution traffic (every day), or you have more temporary addresses and old prefixes hanging around for longer (during a ren umbering event, which is presumably not every day). Temporary addresses don't belong in the DNS. Stale information doesn't be long in the DNS. This seems like a no-brainer to me. -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
Op 3 mrt. 2015, om 21:50 heeft Curtis Villamizar cur...@ipv6.occnc.com het volgende geschreven: In message CAGnRvuq+kq+djqPvKHDXBdDkbfjt=gnj0owqvc241vllwxb...@mail.gmail.com Henning Rogge writes: On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: The basis for the metric in RFC 7181 is out of scope. So what did you use? This: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04 It seems like with this draft, packet with RFC 5444 (Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format) sequence numbers are counted and absent any of those, only HELLO packets are counted. If all packets had RFC 5444 sequence numbers this would have the same effect as LQM. Unfortunately this requires the host to use RFC 5444 encapsulation over WiFi. Unfortunately LQM requires both side to play. On the bright side, a host would only need to copy counters into a packet to allow the AP to gather information. I am still using the multicast loss (plus the raw link speed) to judge the links, but I have done some early experiments with integrating the L2 frame statistics too. Not sure it works that well for wifi without a lot of probing, much more than you need for getting an useful link speed). It would be nice to write down somewhere (preferably and internet-draft for WG purposes) exactly what you end up with once you've made good progress on this. Also I'm not sure what you meant by the MPR code. Did you leave in the LINK_METRIC TLV and leave out the rest of RFC 7181? Multipoint Relays. Its a method to reduce the flooding overhead in a wireless mesh network. Its defined in RFC 7181, but its a modification of NHDP so I put it into my NHDP implementation. So my point still stands that there is nothing like LQM is anything over WiFi (more correctly 802.11). With an Atheros card I get both transmitted frames, retransmitted frames and (completely) lost frames on the sender side of a link... its just that these values are not that useful when most of your wireless links are not transporting traffic. Henning Rogge Its great that you are working on wireless mesh networks. IMHO the typical homenet environment is Ethernet plus WiFi in AP mode, not mesh. Its good to have things that work well for mesh. Right now it would be really good to have solutions for the problem of lots of AP in a confined area. In some cases, such as appartment buildings with lots of consumer run AP, the issue is keeping the density of AP from congesting airwaves. With 5GHz, signal fades away rather quickly due to walls. This has as a disadvantage that even in moderate sized homes, there are multiple 5GHz APs needed for good performance (20Mbps). So the number of WiFi AP's in homes will grow and there's a need for support of IEEE 802.11k and 802.11r. With 802.11ad, walls block RF. In other cases (such as IETF, or an enterprise with lots of APs) hosts will be roaming among APs and that should be smoother than it is now. Unfortunately I don't think that is fixable with zero host changes. In today's WiFi stack and good WLAN controller, this works quite well. Next step is home wireless routers. This homenet WG should catch up. Teco Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Tuesday, March 3, 2015, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: I still think there needs to be quite a lot of work done on APIs and best common practices in order for applications to do the right thing so this kind of renumbering event works. Most likely it's going to require a FOSS library that will act as a middle layer between the application and the network What are the applications that you think would benefit from that? UDP-based applications, mind you, since MP-TCP works marvelously for TCP. We probably need a 5-10 (wo)man-year effort with a FOSS code outcome in order to get this done. I don't know who's interested in doing this. I think getting thoroughly acquainted with previous art is necessary. I'm sure there are other UDP-based applications than just Mosh and µTP-based BitTorrent that can deal with changing addresses, and we don't want to build something that's either too general, not general enough, or even both at the same time. -- Juliusz I think ILNP covers a lot of this work. Yes, it is a big step. But it is a good step. CB ___ homenet mailing list homenet@ietf.org javascript:; https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
On Mar 3, 2015, at 4:55 PM, Ray Hunter v6...@globis.net wrote: One hour TTL could mean 24 times the DNS traffic compared to that historic norm. It also could mean (re)signing DNSSEC zones more than 24 times per day as hosts move around the homenet... Caching is really only interesting for query clusters and frequently accessed domains. I don't think there is any reason to expect that there will be performance issues for homenet names, which I would expect would be infrequently accessed by relatively few resolvers. You either have more name resolution traffic (every day), or you have more temporary addresses and old prefixes hanging around for longer (during a renumbering event, which is presumably not every day). Temporary addresses don't belong in the DNS. Stale information doesn't belong in the DNS. This seems like a no-brainer to me. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On Mar 2, 2015, at 9:05 PM, Michael Thomas m...@mtcc.com wrote: On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says Hi, I'm your friendly homenet router and here's my public key. so you're mollified if somebody's cert says hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx instead? Actually, I’m suspicious, which is entirely appropriate. If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key. the possession of a cert does nothing in and of itself to make an enrollment decision. I agree that the cert itself does nothing. The name in the cert, as long as it isn’t self signed, provides a trust anchor. Mike ___ 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] 6renum redux [Routing protocol comparison document]
On Tue, 3 Mar 2015, Ted Lemon wrote: This is probably the use case we most care about. I think it's actually a strong argument for going with a longer deprecation period. E.g., if your deprecation period were three hours, we simply wouldn't have a problem. I don't agree with this at all. I can easily come up with an equivalent scenario that would require an even longer overlap in time, for instance a long video conferencing session, and also there are longer movies than 3 hours. We need to make applications be able to renumber to new addresses, and it doesn't matter if the use-case is that they're moving between APs, going from fixed to wifi to mobile, or they're being renumbered within the existing access method. Applications need to stop to rely on the address being stable over time. We need to give application developers the tools they need to not have to care about this, which means they need to have some kind of middleware, be it MP-TCP or something else. This needs to be easy for the most common use-cases, and it needs to be transparent to the application developer. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] MPVD requirments in homenet
Liang, what do you mean by multiple services? if you mean walled garden, the homenet architecture only has the following to say: It should be noted that some multihoming scenarios may see one upstream being a walled garden and thus only appropriate for connectivity to the services of that provider; an example may be a VPN service that only routes back to the enterprise business network of a user in the homenet. As per Section 4.2.1 of [RFC3002], we do not specifically target walled-garden multihoming as a goal of this document. cheers, Ole On 03 Mar 2015, at 10:30 , Liang Geng liang.g...@hotmail.com wrote: Hi all, I'm Liang from China Mobile, a recent follower of this community. Following a previous thread concerning the discussion of MPVD in Homenet on 3rd Feb, I personally think that certain use cases are quite well in line with the mif MPVD scenario. As homenet architecture provides autonomic network configuration in future multi-service, multi-homed environment, I think it is also a new challenge in terms of CPE management. My immature thought would be that MPvD may provide a promising model. May I propose the following problems for the list to see if it is worthy of some serious investigation, on which hopefully would be something interesting I could make a brief draft for further discussion (maybe in Dallas meeting)? Problems to be addressed 1. Use case of MPVD in homenet -Single ISP, multiple services (covers single/multiple CE router(s)) -Multiple ISP, multiple services (covers single/multiple CE router(s)) 2. The association of PvD and network configuration in homenet -Address configuration -Naming and service discovery For both, now thinking of a new PvD TLV which enables the association of certain configuration and PvD. Initial thought would be that no DHCP option extension is needed terms of HNCP based pvd coveying. Host and non-HNCP routers may refer to mif work on how pvd information is provided. ...more to be discussed and added Any comments would be extremely welcome. Best wishes Liang ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Mon, Mar 02, 2015 at 07:48:24PM -0500, Curtis Villamizar wrote: The way IETF has normally done things is to allow multiple developments to exist if they have support and then drop only those that are not being deployed or prove to be less desirable. Having multiple examples of running code is certainly a good thing. Discussing all potential approaches to death, unless the committee has won, and the result is an unimplementable nightmare of myriads of different options is what IETF WGs have changed to in more recent years - and if I look at the last few rounds of discussions, I can certainly understand why Dave moved off to get something *done*. A: here's a draft that got implemented, works, and needs feedback but I want ISIS! and I want OSPF! goto A gert, tempted to call it a day and spend my time *deploying* IPv6 somewhere -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] MPVD requirments in homenet
Hi all, I'm Liang from China Mobile, a recent follower of this community. Following a previous thread concerning the discussion of MPVD in Homenet on 3rd Feb, I personally think that certain use cases are quite well in line with the mif MPVD scenario. As homenet architecture provides autonomic network configuration in future multi-service, multi-homed environment, I think it is also a new challenge in terms of CPE management. My immature thought would be that MPvD may provide a promising model. May I propose the following problems for the list to see if it is worthy of some serious investigation, on which hopefully would be something interesting I could make a brief draft for further discussion (maybe in Dallas meeting)? Problems to be addressed 1. Use case of MPVD in homenet -Single ISP, multiple services (covers single/multiple CE router(s)) -Multiple ISP, multiple services (covers single/multiple CE router(s)) 2. The association of PvD and network configuration in homenet -Address configuration -Naming and service discovery For both, now thinking of a new PvD TLV which enables the association of certain configuration and PvD. Initial thought would be that no DHCP option extension is needed terms of HNCP based pvd coveying. Host and non-HNCP routers may refer to mif work on how pvd information is provided. ...more to be discussed and added Any comments would be extremely welcome. Best wishes Liang ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
