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

2015-03-03 Thread Mikael Abrahamsson

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

2015-03-03 Thread Christian Hopps

 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]

2015-03-03 Thread Ted Lemon
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]

2015-03-03 Thread Ted Lemon
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]

2015-03-03 Thread Mikael Abrahamsson

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

2015-03-03 Thread Michael Thomas

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]

2015-03-03 Thread Michael Sweet
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]

2015-03-03 Thread Michael Sweet
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]

2015-03-03 Thread Markus Stenberg
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]

2015-03-03 Thread Ray Hunter



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

2015-03-03 Thread Gert Doering
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]

2015-03-03 Thread Mikael Abrahamsson

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]

2015-03-03 Thread Ted Lemon
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

2015-03-03 Thread Liang Geng
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

2015-03-03 Thread Mikael Abrahamsson

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]

2015-03-03 Thread Mikael Abrahamsson

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

2015-03-03 Thread Michael Behringer (mbehring)
  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]

2015-03-03 Thread Henning Rogge
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]

2015-03-03 Thread Brian E Carpenter


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]

2015-03-03 Thread Curtis Villamizar
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]

2015-03-03 Thread Ted Lemon
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

2015-03-03 Thread Michael Richardson

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]

2015-03-03 Thread Curtis Villamizar
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]

2015-03-03 Thread Ray Hunter

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]

2015-03-03 Thread Mark Andrews

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]

2015-03-03 Thread Mark Andrews

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]

2015-03-03 Thread Mark Andrews

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]

2015-03-03 Thread Mikael Abrahamsson

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]

2015-03-03 Thread Mikael Abrahamsson

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]

2015-03-03 Thread Ray Hunter

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]

2015-03-03 Thread Mark Andrews

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]

2015-03-03 Thread Teco Boot

 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]

2015-03-03 Thread Ca By
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]

2015-03-03 Thread Ted Lemon
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

2015-03-03 Thread David Oran

 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]

2015-03-03 Thread Mikael Abrahamsson

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

2015-03-03 Thread Ole Troan
Liang,

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

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

cheers,
Ole


 On 03 Mar 2015, at 10:30 , Liang Geng 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

2015-03-03 Thread Gert Doering
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

2015-03-03 Thread Liang Geng
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