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

[Brian E Carpenter]

On 04/03/2015 23:12, Ole Troan wrote:
>>> Much as I love MPTCP, it only helps TCP sessions. And it requires both
>>> hosts to
>>> be updated to be effective.
>>
>> IPv6 multi-prefix multi-homing requires both hosts to support it. which 
>> means transport fixes.
> 
> to reply to myself. is anyone aware of any document describing the 
> "expectations for hosts / host gaps" with regards to IPv6 multi-prefix 
> multi-homing? including renumbering, mobility, redundancy, load sharing... 
> essentially the RFC3582 goals.

The best I've got is the set of MULTI6 deliverables:

Goals for IPv6 Site-Multihoming Architectures (RFC 3582)
IPv4 Multihoming Practices and Limitations (RFC 4116)
Architectural Approaches to Multi-Homing for IPv6 (RFC 4177)
Threats relating to IPv6 Multihoming Solutions (RFC 4218)
Things Multihoming in IPv6 (MULTI6) Developers Should Think About (RFC 4219)

   Brian

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

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

[Brian E Carpenter]

On 04/03/2015 22:22, Ole Troan wrote:
>> Much as I love MPTCP, it only helps TCP sessions. And it requires both
>> hosts to
>> be updated to be effective.
> 
> IPv6 multi-prefix multi-homing requires both hosts to support it. which means 
> transport fixes.

Or fully operational shim6, which was conceived and designed for this
exact problem.

   Brian

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

Re: [homenet] L2 link status [was: More about marginal links]

[Teco Boot]

> Op 4 mrt. 2015, om 17:45 heeft Dave Taht  het volgende 
> geschreven:
>>> 
>>> 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.
> 
> Um, no. Today's wifi stacks and most chipsets and drivers are
> horribly, horribly borken.

My telco offered me a free iPhone 6 so I can offload :-)) 
It works very well, I enjoy it at work.
https://support.apple.com/en-la/HT202628

Some say iOS is 2 years behind Android / Nexus 4:
http://uk.businessinsider.com/graphic-iphone-6-v-nexus-4-2014-9?r=US
So Android WiFi roaming should work also (and sometimes, it does).

I am looking for a good solution for homes. Cheapest enterprise level of WiFi 
equipment costs at least 3x more than an a set of high-end wireless routers. On 
roaming, it works 1000x as good, so one can say it is value for money.

Back to homenet topics: zero-conf layer-3 topologies with SADR is great. But 
ignoring IEEE802.11 / WiFi standards sounds crazy to me. Please, let's not make 
it worse.

And yes, I highly respect your efforts making WiFi and AQM better. But this is 
less related to homenet work.

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

Re: [homenet] L2 link status [was: More about marginal links]

[Mikael Abrahamsson]

On Wed, 4 Mar 2015, Dave Taht wrote:


With 5GHz, signal fades away rather quickly due to walls.


False. It is mostly the low signal strength that is legal on the lower
5ghz bands that is the problem here. Higher bands usually let you have
much more output power. But, that too creates problems. See above for
one piece of a solution.


Could you please elaborate? I have read papers claiming 5GHz and 2.4GHz 
attenuates identically through concrete. My personal experience is exactly 
the opposite, that with 20cm re-inforced concrete floors or walls, 5GHz 
basically doesn't work at all, whereas 2.4GHz works ok. I don't believe 
this is only due to lower power output, but I'd gladly be convinced why I 
am wrong.


I thought it was quite obvious that the higher the frequency, the lower 
the solid object penetration is.


Thankfully, although I am waiting for products to appear and it appears 
this standard is mostly targetted at TV, not interactive applications.


I have been told 60Ghz is line-of-sight only, which I have no trouble 
believing. My experience with 38GHz radio links has shown me how little it 
takes to make things stop working compared to 2.4GHz or 5 GHz.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] L2 link status [was: More about marginal links]

[Dave Taht]

On Tue, Mar 3, 2015 at 11:27 PM, Teco Boot  wrote:
>
>> Op 3 mrt. 2015, om 21:50 heeft Curtis Villamizar  het 
>> volgende geschreven:
>>
>> In message 
>> 
>> Henning Rogge writes:
>>
>>> On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar  
>>> 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

My best (well, worst) dataset here was in paris where in my 18th floor
apartment I could "hear" over 200 APs, and was generally lucky to get
a few dozen k in throughput from across the room. 5ghz was illegal at
the time, it was all 2.4ghz traffic.

As I recall, Mark Townsley also had trouble getting 2.4 ghz signal or
bandwidth from across the room in his apt there, also.

>> AP, the issue is keeping the density of AP from congesting airwaves.

Yes.

See the minstrel-blues work - which looks to make a dent in that
problem by reducing signal strength whenever it makes sense.

http://www.linuxplumbersconf.net/2014/ocw//system/presentations/2439/original/Minstrel-Blues%20@LinuxPlumbers%202014.pdf

> With 5GHz, signal fades away rather quickly due to walls.

False. It is mostly the low signal strength that is legal on the lower
5ghz bands that is the problem here. Higher bands usually let you have
much more output power. But, that too creates problems. See above for
one piece of a solution.

I figure (since I am unsubscribed) this message will bounce. But whatever.

> 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.

h, also.

> With 802.11ad, walls block RF.

Thankfully, although I am waiting for products to appear and it
appears this standard is mostly targetted at TV, not interactive
applications.

>
>>
>> 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.

Um, no. Today's wifi stacks and most chipsets and drivers are
horribly, horribly borken.

>Next step is home wireless routers. This homenet WG should catch up.

+10.

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



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

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

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

[Alexandru Petrescu]

Le 03/03/2015 19:41, Michael Richardson a écrit :


Ole Troan  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.


If you had to do this, and if other implementations dont and break, it's
 because something has to be specified about DHCP-PD Router and Relay.
A spec must tell implementor to do it, otherwise it wont work and break.

(we wrote earlier a draft about this DHCP-PD problem that we'll be glad
to resurrect, or we'll be glad to read other drafts on same topic)

https://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00

Alex




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)



___ 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]

[Ted Lemon]

On Mar 4, 2015, at 5:12 AM, Ole Troan  wrote:
> to reply to myself. is anyone aware of any document describing the 
> "expectations for hosts / host gaps" with regards to IPv6 multi-prefix 
> multi-homing? including renumbering, mobility, redundancy, load sharing... 
> essentially the RFC3582 goals.

No.   This would be a good work item for MIF if nobody's currently working on 
it.

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

Re: [homenet] a modest plugfest proposal

[Ted Lemon]

On Mar 4, 2015, at 4:24 AM, Ray Bellis  wrote:
> (*)  my wife disagrees, though, since July 18th is our wedding anniversary...

Hah, and my wife's birthday.   Unfortunately I'm frequently at IETF on her 
birthday. :(

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

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

[Ted Lemon]

On Mar 4, 2015, at 1:48 AM, Ray Hunter  wrote:
> Doesn't that mean that the (hidden master) DNS server itself also has to be 
> renumbered?

Yes, but not before the zone transfer happens: the old IP address remains valid 
even though it's deprecated.

> And the new content synched with the secondary servers (outside of homenet) 
> in a timely manner, before the old prefixes are expired?

Yes, this has to work reliably, and it also has to work if the secondaries are 
offline for some reason during the period when the old address is still valid 
but deprecated.  I would say that there's probably some glue required here if 
it's not already been documented in the homenet dns work that's been done so 
far.

> Are the values suggested in section 4.2 for SOA appropriate then?

4.2 is not normative.   The values suggested there would not be appropriate for 
a rapid-turnover environment like the one Mikael is describing.

> I understood a zone transfer was only triggered when the SOA contents 
> changed, and that was only checked once the secondary refresh timer had 
> expired.

That's right, but remember that when _any_ record is changed in the zone, the 
zone serial number, and hence the SOA, changes.

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

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

[Ted Lemon]

On Mar 4, 2015, at 3:23 AM, Ray Hunter  wrote:
> How does Homenet either update glue records for the domain on the Internet 
> TLD servers (if the master isn't hidden), or update the configuration of the 
> slave servers to point to the new address of the hidden master (if the master 
> is hidden), within an hour or less?

I think you want an explicit update process for the glue records that is 
triggered by the DHCP server deprecating the old address.   This would be 
related to how glue records are set up initially.   The current document 
doesn't actually say anything about this, and that is a weakness that probably 
needs to be addressed.

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

Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt

[Ray Hunter]

Daniel Migault wrote:

Hi,

Please find the new version of DHCP Options for Homenet Naming 
Architecture 
.


The issue raised on the previous version was how these options were 
compatible with multiple ISPs. This use case is illustrated in section 
A. 4 multiple ISPs.


BR,
Daniel


-- Forwarded message --
From: mailto:internet-dra...@ietf.org>>
Date: Tue, Feb 17, 2015 at 8:33 PM
Subject: [homenet] I-D Action: 
draft-ietf-homenet-naming-architecture-dhc-options-01.txt

To: i-d-annou...@ietf.org 
Cc: homenet@ietf.org 



A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 This draft is a work item of the Home Networking Working Group of the 
IETF.


Title   : DHCP Options for Homenet Naming Architecture
Authors : Daniel Migault
  Wouter Cloetens
  Chris Griffiths
  Ralf Weber
Filename: 
draft-ietf-homenet-naming-architecture-dhc-options-01.txt

Pages   : 28
Date: 2015-02-16

Abstract:
   CPEs are usually constraint devices with reduced network and CPU
   capacities.  As such, a CPE hosting on the Internet the authoritative
   naming service for its home network may become vulnerable to resource
   exhaustion attacks.  One way to avoid exposing CPE is to outsource
   the authoritative service to a third party.  This third party can be
   the ISP or any other independent third party.

   Outsourcing the authoritative naming service to a third party
   requires setting up an architecture which may be unappropriated for
   most end users.  To leverage this issue, this document proposes DHCP
   Options so any agnostic CPE can automatically proceed to the
   appropriated configuration and outsource the authoritative naming
   service for the home network.  This document shows that in most
   cases, these DHCP Options make outsourcing to a third party (be it
   the ISP or any ISP independent service provider) transparent for the
   end user.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-naming-architecture-dhc-options-01


Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org 
.


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



--
Daniel Migault
Ericsson
I finally got around to reading this draft. It's been on my todo list 
for some time,


It looks very good, but I am missing the detail of how a renumbering 
event would be handled.


Is that the same process as adding a new Homenet CPE?

Worst case would seem to be where a user chooses scenario A3, but the 
ISP initiates a renumbering event without warning/coordination (new PD 
prefix).


My understanding of the plumbing is that something like BIND running on 
the Public Authoritative Master(s)  (slaves) would be hard-coded with a 
fixed IP addresses pointing at the hidden master running on the Homenet.
Configuring multiple masters is possible in BIND, so that's not an 
insurmountable barrier, and it would be possible to run with both 
addresses from the old and new prefixes simultaneously, and let BIND 
work out which one was reachable.


But maybe if the NOTIFY process in Section 5.1.1 from the CPE to the 
Public Authoritative Master(s) anyway already contains the address from 
the new prefix, and the process already checks validity and reachability 
of the hidden master before replacing the old entry, then maybe there's 
no need to run with multiple masters for any overlapping time at all.


The timing intrigues me.

--
Regards,
RayH

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

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

[Ole Troan]

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

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

cheers,
Ole


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

Re: [homenet] a modest plugfest proposal

[Pierre Pfister]

Hello hackers !

As often now, Homenet implementation (http://www.homewrt.org/ - slightly 
outdated doc) will be present at BnB.

And as usual, we will prepare the demo from Monday to Thursday evening. i.e., 
be present in the route fighting with wires.

Please feel free to come se me/us with or without your own routers. Anytime.
It would be my/our pleasure to help you install homenet, test and discuss.

Cheers,

- Pierre



>> Since there is no interest in this working group in actually testing it's own
>> effluent, in what exists as running code so far, and prefers instead to 
>> re-raise
>> old debates, and come up with unworkable alternatives, and otherwise
>> waste my time - and openwrt chaos calmer is going freeze in a month or two
>> and there is plenty of real work to do on that that can actually make a
>> difference -
>> 
>> I am unsubscribing from this list. With great joy.
> 
> Oh. And I was hoping that some sort of informal plugfest really could be 
> organized. I was thinking I'd go get one of those suggested routers this 
> weekend and bring it to Dallas to take advantage of availability of expert 
> help in jump-starting my experimentation with the various protocol options on 
> my 2 6rd IPv6 connections (one from a cable operator and one from a telco). 
> I'm really intrigued by potential solutions that would make it easy for me to 
> connect my network to both upstream connections at the same time. I'm not 
> scared of NPTv6. I am concerned with the fact that my big bandwidth 
> connection has higher latency than my itty-bitty low bandwidth connection. I 
> don't think I want to rely on Happy Eyeballs to pick the right one.
> 
> Are you sure you won't reconsider?
> Barbara
> ___
> 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]

[Mikael Abrahamsson]

On Wed, 4 Mar 2015, Ole Troan wrote:


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


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


Yes, as far as I can see there are only two ways to fix this, either you 
fix one end and this would require tunneling for the client that wants to 
be endpoint address independent (LISP or something else), or if you fix 
both ends, you could use MPTCP, SHIM6 etc.


So one way of doing this would be to use tunneling approach for traffic 
that isn't address-independent, and MPTCP/SHIM6 approach with direct 
routing for things that are (I guess this would require some MIF/PVD kind 
of approach). This of course means you have to have a decent notion about 
what is what, which either means caching results (this DST address seems 
to support address-independence protocol BLAH), or it means explicitly 
telling the client about it (DNS SRV records or something), or both.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] a modest plugfest proposal

[Ray Bellis]

[catching up after a day off sick]

> On 3 Mar 2015, at 02:09, Ted Lemon  wrote:
> 
> I think there is interest.   I'm certainly interested.   But plugfests and 
> working group meetings are two different things, and it's too close to the 
> meeting to plan a plugfest, because they require infrastructure.  

As you say, WG sessions and Plugfests are entirely different meetings.  Having 
tried previously to try to organise space and participants at a previous 
meeting for a short notice plugfest, it just doesn't work.

>  I think we should try to do a plugfest in Prague.   We will be doing a 
> hackathon event in Prague, and this would, I think, fit in.   The plugfest 
> will most likely be the Saturday before the meeting.   If there is interest, 
> we can make it happen.


That does sound like a fine idea(*).

Ray


(*)  my wife disagrees, though, since July 18th is our wedding anniversary...
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ole Troan]

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

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

cheers,
Ole



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

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

[Teco Boot]

> Op 4 mrt. 2015, om 08:48 heeft Mikael Abrahamsson  het 
> volgende geschreven:
> 
> 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.

OpenVPN with float comes nearby.
I'm testing pre-2.4 with fix for float in P2MP mode. Works fine.

However, I do not recommend to use OpenVPN for each and every connection on 
Internet.

Teco


> 
> -- 
> Mikael Abrahamssonemail: 
> swm...@swm.pp.se___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

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

[Ray Hunter]

Mark Andrews 
4 March 2015 08:04
In message<54f6aace.3030...@globis.net>, Ray Hunter writes:

Ted Lemon
4 March 2015 03:21
On Mar 3, 2015, at 4:55 PM, Ray Hunter   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.

Thanks. That rids me of one misconception then.

How does Homenet either update glue records for the domain on the 
Internet TLD servers (if the master isn't hidden), or update the 
configuration of the slave servers to point to the new address of the 
hidden master (if the master is hidden), within an hour or less?


Is that something that can also be automated and e.g. be triggered by an 
existing NOTIFY message?

Or would this mechanism need a new extension?

I'd rather not assume that the ISP was also the DNS provider.

Otherwise the slaves will lose connectivity to the hidden master (if the 
master is hidden) . Or your glue records will be outdated and the name 
resolution won't bootstrap at all (if the master isn't hidden).

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




--
Regards,
RayH

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