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

[Ted Lemon]

On Mar 6, 2015, at 5:00 AM, Ray Hunter  wrote:
> Can this be handled in the Homenet WG? or DNS?

I don't see in principle why homenet couldn't address it.   It appears to be in 
charter.

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

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

[Ray Hunter]

Ted Lemon 
4 March 2015 16:20

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.

Exactly.

Can this be handled in the Homenet WG? or DNS?

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

Brian,

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

right. I tend to think that the problems of multi-homing, multi-endpoint, 
mobility, and renumbering are tightly coupled.
you might need to expose some of this to the transport and applications. I have 
more hope of solving this at L4.5 or even L5 (I suppose talking about a 
“session layer” would get me banned from the IETF. ;-)), than at L3.5.

to take the digression back to homenet; if we agree this is a problem for 
transport or above, then at least we can declare victory by claiming it isn’t 
our problem.

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]

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

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

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

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

[Mark Andrews]

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.

> >> 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] 6renum redux [Routing protocol comparison document]

[Ray Hunter]

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

[Ted Lemon]

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 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] 6renum redux [Routing protocol comparison document]

[Ca By]

On Tuesday, March 3, 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.
>
> > 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 
> 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]

[Mark Andrews]

In message <54f62dda.9020...@globis.net>, Ray Hunter writes:
> > Ted Lemon 
> > 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]

[Ray Hunter]

Ted Lemon 
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]

[Juliusz Chroboczek]

> 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

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

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

[Mark Andrews]

In message , 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]

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

[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] 6renum redux [Routing protocol comparison document]

[Ted Lemon]

On Mar 3, 2015, at 11:42 AM, Ray Hunter  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] 6renum redux [Routing protocol comparison document]

[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] 6renum redux [Routing protocol comparison document]

[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] 6renum redux [Routing protocol comparison document]

[Markus Stenberg]

On 3.3.2015, at 18.04, Michael Sweet  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]

[Michael Sweet]

Mikael,

> On Mar 3, 2015, at 10:34 AM, Mikael Abrahamsson  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]

[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] 6renum redux [Routing protocol comparison document]

[Ted Lemon]

On Mar 3, 2015, at 8:57 AM, Mikael Abrahamsson  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]

[Michael Sweet]

Mikael,

> On Mar 3, 2015, at 8:57 AM, Mikael Abrahamsson  wrote:
> 
> On Tue, 3 Mar 2015, Ted Lemon wrote:
> 
>> This is probably the use case we most care about.  I think it's actually a 
>> strong argument for going with a longer deprecation period.  E.g., if your 
>> deprecation period were three hours, we simply wouldn't have a problem.
> 
> I don't agree with this at all.
> 
> I can easily come up with an equivalent scenario that would require an even 
> longer overlap in time, for instance a long video conferencing session, and 
> also there are longer movies than 3 hours.

True, but most video conferencing software and live video feeds handle 
disconnects gracefully (enough) already, and most streaming video is not done 
using a single file/URL but with a series of files/URLs, with each file/URL 
representing a  "chapter" or other divisible unit within the program/movie 
being watched - there you will either seamlessly transition to the new address 
when the next chapter is fetched, or the application will detect the lost 
connection/stalled data and then attempt a reconnect which gets the new address.

So don't assume there will be problems when a network is renumbered - a lot of 
the work that's been done to deal with unreliable networks is equally useful 
for network changes, so long as the client application does not assume the 
network address of a named service won't change.

_
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

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

[Mikael 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] 6renum redux [Routing protocol comparison document]

[Ted Lemon]

On Mar 3, 2015, at 8:20 AM, Mikael Abrahamsson  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] 6renum redux [Routing protocol comparison document]

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

[Ted Lemon]

On Mar 3, 2015, at 3:24 AM, Mikael Abrahamsson  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]

[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] 6renum redux [Routing protocol comparison document]

[Brian E Carpenter]

On 03/03/2015 13:26, Curtis Villamizar wrote:
> In message <54f4d7bb.3050...@gmail.com>
> Brian E Carpenter writes:
>  
>> Hi Toerless,
>> On 03/03/2015 10:23, Toerless Eckert wrote:
>>> Would any of those rfc explain to me what the problems with renumbering
>>> in a homenet are that Fave tried to avoid by doing NAT ? And how
>>> those issues can not be mitigated by better workarounds than NAT ?
>>  
>> http://tools.ietf.org/html/rfc7010 is the gap analysis, but for
>> enterprise networks. I think what Dave is actually saying is that
>> complex home networks of the future (which is where he already lives)
>> inherit many of these problems, with difference that renumbering
>> will be imposed by the ISP, so the element of choice and planning
>> that an enterprise network has is missing.
>>  
>> Somebody needs to work on RFC7010-for-homenet, I guess.
> 
> Its zero conf.  It just happens.  Seriously.

Well, Dave is saying he's tried and it doesn't. Whether that
means he has a printer with a manually configured non-ULA IPv6
address, or something else, I don't know, but we need to
understand.

Brian

> 
> OTOH, if there are devices with configured addresses then it would be
> nice if the person running the network knew what they were, where
> they were located, and how to access them to make changes.
> 
>> (Curtis is right, of course: if a network is designed and
>> managed with renumbering treated as an expected event, life
>> would be better.)
>>  
>> Brian
> 
> Its really not a matter of treated renumbering as an expected event.
> Good network planning results in knowing how you've allocated subnets,
> which servers were given fixed addresses, and what DHCP pools exist.
> Good network management involves also checking to see that hosts you
> see for fixed addresses you don't know about including those within
> the pools (no DHCP lease in the logs but something there at the top
> range of the pool).  Its also nice to know when a rogue host or DHCP
> server shows up and have the means to isolate its physical location.
> For example, a box that went nuts and started spewing packets.
> 
> That type of good planning and good management leads to a simple and
> straightforward renumbering as long as there is a grace period for the
> transition.  If maintenance of configs is automated, then the renumber
> can be done in record time.
> 
> Curtis
> 
> 
>>> On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote:
 Admittedly 6renum was targetted at enterprise networks, partly because
 of the
 observation that homenets renumber anyway after every power cut. But
 we have spent a lot of cycles on this issue.

 http://tools.ietf.org/html/rfc4192
 http://tools.ietf.org/html/rfc5887
 http://tools.ietf.org/html/rfc6866
 http://tools.ietf.org/html/rfc6879
 http://tools.ietf.org/html/rfc7010
 and maybe it's time to revive
 https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines

Brian


 On 01/03/2015 12:40, Curtis Villamizar wrote:
> In message 
> 
> Dave Taht writes:
>  
>> On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
>>  wrote:
>>> In message <54ee258e.8060...@gmail.com>
>>> Brian E Carpenter writes:
>>>
 On 26/02/2015 05:14, Mikael Abrahamsson wrote:
> On Wed, 25 Feb 2015, Ray Hunter wrote:
>
>> That way the devices can roam at L3, without all of the nasty side 
>> effects of re-establishing TPC sessions, or updating
>> dynamic naming services, or having to run an L2 overlay network 
>> everywhere, or having to support protocols that require a
>> specialised partner in crime on the server side (mTCP, shim6 et al).
>
> It's my firm belief that we need to rid clients of IP address 
> dependence for its sessions. Asking clients to participate in HNCP
> only addresses the problem where HNCP is used.
>
> Fixing this for real would reap benefits for devices moving between 
> any kind of network, multiple providers, mobile/fixed etc.

 Violent agreement. This is not a homenet problem; it's an IP problem.
 In fact, it's exactly why IP addresses are considered harmful in
 some quarters. Trying to fix it just for homenet seems pointless.
 http://www.sigcomm.org/ccr/papers/2014/April/000.008

Brian
>>>
>>>
>>> Brian,
>>>
>>> Seriously - your paper may be overstating the problem.  At least if we
>>> discount IPv4 and in doing so eliminate NAT we solve a lot of problems
>>> that never should have existed in the first place.  If we carry NAT
>>> over to IPV6, then shame on us.
>>  
>> I am sorry, I no longer share this opinion. The pains of renumbering
>> someones entire home network every time the ISP feels like it, given
>> the enormous number of devices I h

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

[STARK, BARBARA H]

> I can understand why this is done in IPv4 (not enough address space) but this
> does not apply to IPv6.

Just as one point where it does apply: 6rd deployments experience 
"fate-sharing" of the IPv6 address prefix with the IPv4 address. In PPPoE-based 
architectures, the IPv4 address is known to change relatively frequently. 
Barbara

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

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

[Curtis Villamizar]

In message <54f4d7bb.3050...@gmail.com>
Brian E Carpenter writes:
 
> Hi Toerless,
> On 03/03/2015 10:23, Toerless Eckert wrote:
> > Would any of those rfc explain to me what the problems with renumbering
> > in a homenet are that Fave tried to avoid by doing NAT ? And how
> > those issues can not be mitigated by better workarounds than NAT ?
>  
> http://tools.ietf.org/html/rfc7010 is the gap analysis, but for
> enterprise networks. I think what Dave is actually saying is that
> complex home networks of the future (which is where he already lives)
> inherit many of these problems, with difference that renumbering
> will be imposed by the ISP, so the element of choice and planning
> that an enterprise network has is missing.
>  
> Somebody needs to work on RFC7010-for-homenet, I guess.

Its zero conf.  It just happens.  Seriously.

OTOH, if there are devices with configured addresses then it would be
nice if the person running the network knew what they were, where
they were located, and how to access them to make changes.

> (Curtis is right, of course: if a network is designed and
> managed with renumbering treated as an expected event, life
> would be better.)
>  
> Brian

Its really not a matter of treated renumbering as an expected event.
Good network planning results in knowing how you've allocated subnets,
which servers were given fixed addresses, and what DHCP pools exist.
Good network management involves also checking to see that hosts you
see for fixed addresses you don't know about including those within
the pools (no DHCP lease in the logs but something there at the top
range of the pool).  Its also nice to know when a rogue host or DHCP
server shows up and have the means to isolate its physical location.
For example, a box that went nuts and started spewing packets.

That type of good planning and good management leads to a simple and
straightforward renumbering as long as there is a grace period for the
transition.  If maintenance of configs is automated, then the renumber
can be done in record time.

Curtis


> > On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote:
> >> Admittedly 6renum was targetted at enterprise networks, partly because
> >> of the
> >> observation that homenets renumber anyway after every power cut. But
> >> we have spent a lot of cycles on this issue.
> >>
> >> http://tools.ietf.org/html/rfc4192
> >> http://tools.ietf.org/html/rfc5887
> >> http://tools.ietf.org/html/rfc6866
> >> http://tools.ietf.org/html/rfc6879
> >> http://tools.ietf.org/html/rfc7010
> >> and maybe it's time to revive
> >> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
> >>
> >>Brian
> >>
> >>
> >> On 01/03/2015 12:40, Curtis Villamizar wrote:
> >>> In message 
> >>> 
> >>> Dave Taht writes:
> >>>  
>  On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
>   wrote:
> > In message <54ee258e.8060...@gmail.com>
> > Brian E Carpenter writes:
> >
> >> On 26/02/2015 05:14, Mikael Abrahamsson wrote:
> >>> On Wed, 25 Feb 2015, Ray Hunter wrote:
> >>>
>  That way the devices can roam at L3, without all of the nasty side 
>  effects of re-establishing TPC sessions, or updating
>  dynamic naming services, or having to run an L2 overlay network 
>  everywhere, or having to support protocols that require a
>  specialised partner in crime on the server side (mTCP, shim6 et al).
> >>>
> >>> It's my firm belief that we need to rid clients of IP address 
> >>> dependence for its sessions. Asking clients to participate in HNCP
> >>> only addresses the problem where HNCP is used.
> >>>
> >>> Fixing this for real would reap benefits for devices moving between 
> >>> any kind of network, multiple providers, mobile/fixed etc.
> >>
> >> Violent agreement. This is not a homenet problem; it's an IP problem.
> >> In fact, it's exactly why IP addresses are considered harmful in
> >> some quarters. Trying to fix it just for homenet seems pointless.
> >> http://www.sigcomm.org/ccr/papers/2014/April/000.008
> >>
> >>Brian
> >
> >
> > Brian,
> >
> > Seriously - your paper may be overstating the problem.  At least if we
> > discount IPv4 and in doing so eliminate NAT we solve a lot of problems
> > that never should have existed in the first place.  If we carry NAT
> > over to IPV6, then shame on us.
>   
>  I am sorry, I no longer share this opinion. The pains of renumbering
>  someones entire home network every time the ISP feels like it, given
>  the enormous number of devices I have encountered that don't handle it
>  well, are just too much to bear.
> >>>
> >>> I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to
> >>> ANSNET as part of the NSFNET decommissioning).  Not by myself of
> >>> course, but there were only a few of us on this.  It wasn't all that
> >>> bad and we had

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

[Mark Andrews]

In message <54f4d7bb.3050...@gmail.com>, Brian E Carpenter writes:
> Hi Toerless,
> On 03/03/2015 10:23, Toerless Eckert wrote:
> > Would any of those rfc explain to me what the problems with renumbering
> > in a homenet are that Fave tried to avoid by doing NAT ? And how
> > those issues can not be mitigated by better workarounds than NAT ?
> 
> http://tools.ietf.org/html/rfc7010 is the gap analysis, but for
> enterprise networks. I think what Dave is actually saying is that
> complex home networks of the future (which is where he already lives)
> inherit many of these problems, with difference that renumbering
> will be imposed by the ISP, so the element of choice and planning
> that an enterprise network has is missing.

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.

I can understand why this is done in IPv4 (not enough address space)
but this does not apply to IPv6.

If the equipement / software ISP's are using can't support multiple
prefixes then log fault reports with the suppliers.  Multiple
prefixes have been part of IPv6 from the very beginning.

> Somebody needs to work on RFC7010-for-homenet, I guess.
> 
> (Curtis is right, of course: if a network is designed and
> managed with renumbering treated as an expected event, life
> would be better.)
> 
> Brian
> 
> > 
> > On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote:
> >> Admittedly 6renum was targetted at enterprise networks, partly because
> >> of the
> >> observation that homenets renumber anyway after every power cut. But
> >> we have spent a lot of cycles on this issue.
> >>
> >> http://tools.ietf.org/html/rfc4192
> >> http://tools.ietf.org/html/rfc5887
> >> http://tools.ietf.org/html/rfc6866
> >> http://tools.ietf.org/html/rfc6879
> >> http://tools.ietf.org/html/rfc7010
> >> and maybe it's time to revive
> >> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
> >>
> >>Brian
> >>
> >>
> >> On 01/03/2015 12:40, Curtis Villamizar wrote:
> >>> In message  l.com>
> >>> Dave Taht writes:
> >>>  
>  On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
>   wrote:
> > In message <54ee258e.8060...@gmail.com>
> > Brian E Carpenter writes:
> >
> >> On 26/02/2015 05:14, Mikael Abrahamsson wrote:
> >>> On Wed, 25 Feb 2015, Ray Hunter wrote:
> >>>
>  That way the devices can roam at L3, without all of the nasty side e
> ffects of re-establishing TPC sessions, or updating
>  dynamic naming services, or having to run an L2 overlay network ever
> ywhere, or having to support protocols that require a
>  specialised partner in crime on the server side (mTCP, shim6 et al).
> >>>
> >>> It's my firm belief that we need to rid clients of IP address depende
> nce for its sessions. Asking clients to participate in HNCP
> >>> only addresses the problem where HNCP is used.
> >>>
> >>> Fixing this for real would reap benefits for devices moving between a
> ny kind of network, multiple providers, mobile/fixed etc.
> >>
> >> Violent agreement. This is not a homenet problem; it's an IP problem.
> >> In fact, it's exactly why IP addresses are considered harmful in
> >> some quarters. Trying to fix it just for homenet seems pointless.
> >> http://www.sigcomm.org/ccr/papers/2014/April/000.008
> >>
> >>Brian
> >
> >
> > Brian,
> >
> > Seriously - your paper may be overstating the problem.  At least if we
> > discount IPv4 and in doing so eliminate NAT we solve a lot of problems
> > that never should have existed in the first place.  If we carry NAT
> > over to IPV6, then shame on us.
>   
>  I am sorry, I no longer share this opinion. The pains of renumbering
>  someones entire home network every time the ISP feels like it, given
>  the enormous number of devices I have encountered that don't handle it
>  well, are just too much to bear.
> >>>
> >>> I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to
> >>> ANSNET as part of the NSFNET decommissioning).  Not by myself of
> >>> course, but there were only a few of us on this.  It wasn't all that
> >>> bad and we had about 2,000 things to renumber in hundreds of
> >>> locations, many of them not manned.  Shell scripts and ksh (kerberized
> >>> rsh, not the Korn shell) made it simpler.  The worst was Cisco routers
> >>> and various old DSU/CSU and other commercial stuff since you had to
> >>> use "expect" scripts on their CLI rather than just something of the
> >>> form "ksh fqdn -l root ifconfig newaddr/mask alias" People with root
> >>> on their workstation that didn't give us acess were given notice.  We
> >>> used interface aliases and gradually took down the old aliases and
> >>> subnet addresses.  Nothing critical was affected.  It took a day or
> >>> two, then bake time, then les

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

[Brian E Carpenter]

Hi Toerless,
On 03/03/2015 10:23, Toerless Eckert wrote:
> Would any of those rfc explain to me what the problems with renumbering
> in a homenet are that Fave tried to avoid by doing NAT ? And how
> those issues can not be mitigated by better workarounds than NAT ?

http://tools.ietf.org/html/rfc7010 is the gap analysis, but for
enterprise networks. I think what Dave is actually saying is that
complex home networks of the future (which is where he already lives)
inherit many of these problems, with difference that renumbering
will be imposed by the ISP, so the element of choice and planning
that an enterprise network has is missing.

Somebody needs to work on RFC7010-for-homenet, I guess.

(Curtis is right, of course: if a network is designed and
managed with renumbering treated as an expected event, life
would be better.)

Brian

> 
> On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote:
>> Admittedly 6renum was targetted at enterprise networks, partly because
>> of the
>> observation that homenets renumber anyway after every power cut. But
>> we have spent a lot of cycles on this issue.
>>
>> http://tools.ietf.org/html/rfc4192
>> http://tools.ietf.org/html/rfc5887
>> http://tools.ietf.org/html/rfc6866
>> http://tools.ietf.org/html/rfc6879
>> http://tools.ietf.org/html/rfc7010
>> and maybe it's time to revive
>> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
>>
>>Brian
>>
>>
>> On 01/03/2015 12:40, Curtis Villamizar wrote:
>>> In message 
>>> 
>>> Dave Taht writes:
>>>  
 On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
  wrote:
> In message <54ee258e.8060...@gmail.com>
> Brian E Carpenter writes:
>
>> On 26/02/2015 05:14, Mikael Abrahamsson wrote:
>>> On Wed, 25 Feb 2015, Ray Hunter wrote:
>>>
 That way the devices can roam at L3, without all of the nasty side 
 effects of re-establishing TPC sessions, or updating
 dynamic naming services, or having to run an L2 overlay network 
 everywhere, or having to support protocols that require a
 specialised partner in crime on the server side (mTCP, shim6 et al).
>>>
>>> It's my firm belief that we need to rid clients of IP address 
>>> dependence for its sessions. Asking clients to participate in HNCP
>>> only addresses the problem where HNCP is used.
>>>
>>> Fixing this for real would reap benefits for devices moving between any 
>>> kind of network, multiple providers, mobile/fixed etc.
>>
>> Violent agreement. This is not a homenet problem; it's an IP problem.
>> In fact, it's exactly why IP addresses are considered harmful in
>> some quarters. Trying to fix it just for homenet seems pointless.
>> http://www.sigcomm.org/ccr/papers/2014/April/000.008
>>
>>Brian
>
>
> Brian,
>
> Seriously - your paper may be overstating the problem.  At least if we
> discount IPv4 and in doing so eliminate NAT we solve a lot of problems
> that never should have existed in the first place.  If we carry NAT
> over to IPV6, then shame on us.
  
 I am sorry, I no longer share this opinion. The pains of renumbering
 someones entire home network every time the ISP feels like it, given
 the enormous number of devices I have encountered that don't handle it
 well, are just too much to bear.
>>>
>>> I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to
>>> ANSNET as part of the NSFNET decommissioning).  Not by myself of
>>> course, but there were only a few of us on this.  It wasn't all that
>>> bad and we had about 2,000 things to renumber in hundreds of
>>> locations, many of them not manned.  Shell scripts and ksh (kerberized
>>> rsh, not the Korn shell) made it simpler.  The worst was Cisco routers
>>> and various old DSU/CSU and other commercial stuff since you had to
>>> use "expect" scripts on their CLI rather than just something of the
>>> form "ksh fqdn -l root ifconfig newaddr/mask alias" People with root
>>> on their workstation that didn't give us acess were given notice.  We
>>> used interface aliases and gradually took down the old aliases and
>>> subnet addresses.  Nothing critical was affected.  It took a day or
>>> two, then bake time, then less than a day to remove aliases.
>>>
>>> OTOH - Most homes can't run two prefixes for a week or two before
>>> taking the old prefix down.  And lots of consumer devices don't do
>>> aliases.  But now days there is DHCP which didn't exist then (and
>>> ICMPv6 RS/RA and SLAAC).
>>>
>>> Are you having problems with the provider not giving you a static IPv6
>>> prefix, but rather changing it on a whim?
>>>
>>> I also renumbered my home net multiple times, but again, not much
>>> pain.  Only a few consumer gadgets here have fixed addresses (one
>>> because it never renewed DHCP leases and therefore needed a fixed
>>> address, but that has since been tossed in e-waste recycling).
>

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

[Toerless Eckert]

Would any of those rfc explain to me what the problems with renumbering
in a homenet are that Fave tried to avoid by doing NAT ? And how
those issues can not be mitigated by better workarounds than NAT ?


On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote:
> Admittedly 6renum was targetted at enterprise networks, partly because
> of the
> observation that homenets renumber anyway after every power cut. But
> we have spent a lot of cycles on this issue.
> 
> http://tools.ietf.org/html/rfc4192
> http://tools.ietf.org/html/rfc5887
> http://tools.ietf.org/html/rfc6866
> http://tools.ietf.org/html/rfc6879
> http://tools.ietf.org/html/rfc7010
> and maybe it's time to revive
> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
> 
>Brian
> 
> 
> On 01/03/2015 12:40, Curtis Villamizar wrote:
> > In message 
> > 
> > Dave Taht writes:
> >  
> >> On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
> >>  wrote:
> >>> In message <54ee258e.8060...@gmail.com>
> >>> Brian E Carpenter writes:
> >>>
>  On 26/02/2015 05:14, Mikael Abrahamsson wrote:
> > On Wed, 25 Feb 2015, Ray Hunter wrote:
> >
> >> That way the devices can roam at L3, without all of the nasty side 
> >> effects of re-establishing TPC sessions, or updating
> >> dynamic naming services, or having to run an L2 overlay network 
> >> everywhere, or having to support protocols that require a
> >> specialised partner in crime on the server side (mTCP, shim6 et al).
> >
> > It's my firm belief that we need to rid clients of IP address 
> > dependence for its sessions. Asking clients to participate in HNCP
> > only addresses the problem where HNCP is used.
> >
> > Fixing this for real would reap benefits for devices moving between any 
> > kind of network, multiple providers, mobile/fixed etc.
> 
>  Violent agreement. This is not a homenet problem; it's an IP problem.
>  In fact, it's exactly why IP addresses are considered harmful in
>  some quarters. Trying to fix it just for homenet seems pointless.
>  http://www.sigcomm.org/ccr/papers/2014/April/000.008
> 
> Brian
> >>>
> >>>
> >>> Brian,
> >>>
> >>> Seriously - your paper may be overstating the problem.  At least if we
> >>> discount IPv4 and in doing so eliminate NAT we solve a lot of problems
> >>> that never should have existed in the first place.  If we carry NAT
> >>> over to IPV6, then shame on us.
> >>  
> >> I am sorry, I no longer share this opinion. The pains of renumbering
> >> someones entire home network every time the ISP feels like it, given
> >> the enormous number of devices I have encountered that don't handle it
> >> well, are just too much to bear.
> > 
> > I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to
> > ANSNET as part of the NSFNET decommissioning).  Not by myself of
> > course, but there were only a few of us on this.  It wasn't all that
> > bad and we had about 2,000 things to renumber in hundreds of
> > locations, many of them not manned.  Shell scripts and ksh (kerberized
> > rsh, not the Korn shell) made it simpler.  The worst was Cisco routers
> > and various old DSU/CSU and other commercial stuff since you had to
> > use "expect" scripts on their CLI rather than just something of the
> > form "ksh fqdn -l root ifconfig newaddr/mask alias" People with root
> > on their workstation that didn't give us acess were given notice.  We
> > used interface aliases and gradually took down the old aliases and
> > subnet addresses.  Nothing critical was affected.  It took a day or
> > two, then bake time, then less than a day to remove aliases.
> > 
> > OTOH - Most homes can't run two prefixes for a week or two before
> > taking the old prefix down.  And lots of consumer devices don't do
> > aliases.  But now days there is DHCP which didn't exist then (and
> > ICMPv6 RS/RA and SLAAC).
> > 
> > Are you having problems with the provider not giving you a static IPv6
> > prefix, but rather changing it on a whim?
> > 
> > I also renumbered my home net multiple times, but again, not much
> > pain.  Only a few consumer gadgets here have fixed addresses (one
> > because it never renewed DHCP leases and therefore needed a fixed
> > address, but that has since been tossed in e-waste recycling).
> > 
> >> The next version of cerowrt will do translation from the external IPv6
> >> address range to a static internal one (or ones, in the case of
> >> multiple egress gateways), and lacking a standard for such will use
> >> fcxx/8 addressing. I will make it be an option for people to turn off,
> >> but I've had it with being renumbered.
> > 
> > Are you suggesting that we add NAT to IPv6?  [I ask with disbelief.]
> > 
> > I would definitely be turning that off since I have a plenty big and
> > very static IPv6 prefix.  I also have a (tiny) static IPv4 prefix so I
> > have no choice but to IPv4 NAT due to its tiny size.
> > 
> > A better option m

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

[Curtis Villamizar]

In message <54f26a38.8070...@gmail.com>
Brian E Carpenter writes:
 
> Admittedly 6renum was targetted at enterprise networks, partly because
> of the
> observation that homenets renumber anyway after every power cut. But
> we have spent a lot of cycles on this issue.
>  
> http://tools.ietf.org/html/rfc4192
> http://tools.ietf.org/html/rfc5887
> http://tools.ietf.org/html/rfc6866
> http://tools.ietf.org/html/rfc6879
> http://tools.ietf.org/html/rfc7010
> and maybe it's time to revive
> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
>  
>Brian


Brian,

To summarize my prior inelegantly made point:

  Perhaps the emphasis should not be on "network renumbering is hard"
  encouraging further whining.  The emphasis should not be on "network
  renumbering does not need to be hard but can be very hard if certain
  bad network management practices are followed".

Through some coincidence or bad karma, my colocation provider arranged
for a quick demo.  I was typing through an slogin when I noticed no
response.  To make a long story short the colo provider planned
renumbered into a new IPv6 space, sent a mass email which is probably
in my spam folder (to: undiclosed; bcc: ..the world..), and then did
the renumber.

When I called and heard about this it didn't really bother me partly
since it Sunday.  IPv4 still worked so I could recover.

First fix all of my stored config files in one shot.

  foreach f ( `find * -type f | xargs grep -l 2001:550:3800` )
sed < $f > $f.tmp -e 's,,,g' && mv $f.tmp $f
  end

Then push these out to one bhyve host and two VM.

  gmake REMOTE_HOST= REMOTE_USER=root SSH_AF_ARG=-4 install

Then slogin to each and compare old and new:

  sh build-02-etc-files.sh -cmp | & less

After that check update it

  sh build-02-etc-files.sh -destdir / -targethost 

Then for the VM with jails check first

  foreach j (  )
sh build-03-jails.sh -cmp -destdir /j0/$j -targethost $j |& less
  end

then update

  /etc/rc.d/jail stop
  foreach j (  )
sh build-03-jails.sh -config-only -destdir /j0/$j -targethost $j
  end

then restart the VMs (old interface was used new one is shown):

  /etc/bhyve/rc.d/ restart

Done with everything at the colo site.

Then figure out (very easily, look in a file) who is running a caching
nameserver with DNS secondaries configured to the old addresses.

  if it is not a jail:

gmake REMOTE_HOST= REMOTE_USER=root SSH_AF_ARG=-4 install

  if it is a jail then on the supporting host:

sh build-03-jails.sh -config-only -destdir /j0/ -targethost 

  then

ssh  -l root /usr/local/etc/rc.d/named stop
ssh  -l root rm -f /etc/named/s/*
ssh  -l root /usr/local/etc/rc.d/named start

Done with all hosts

Now just fix DNS glue records at the registrar and done.

The whole thing was under two hours including adding the SSH_AF_ARG
support to a bunch of gmake .mk files.

  2 rackmount servers
  1 destop (DNS only)
  4 VM on the 3 rackmounts
  16 jails on the 4 VMs

  rebuild zone files, named.conf (part of the gmake)
  update sendmail config files
  all system files such as rc.conf and sshd_config
  web server config including virtual host configs

unaffected were kdc and svn server (no fixed addresses).

This was all done remotely (since I still had working IPv4).

Not terribly painful.  But it could have been.  Not planned, but a
quick demo of renummbering something that looks a bit more like an
enterprise network than a homenet (because it is).

Curtis


ps- and no these gmake files and perl and shell stuff is not yet
available anywhere.  Sorry.

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

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

[Curtis Villamizar]

In message <54f26a38.8070...@gmail.com>
Brian E Carpenter writes:
 
> Admittedly 6renum was targetted at enterprise networks, partly because
> of the observation that homenets renumber anyway after every power
> cut. But we have spent a lot of cycles on this issue.
>  
> http://tools.ietf.org/html/rfc4192
> http://tools.ietf.org/html/rfc5887
> http://tools.ietf.org/html/rfc6866
> http://tools.ietf.org/html/rfc6879
> http://tools.ietf.org/html/rfc7010
> and maybe it's time to revive
> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
>  
>Brian


Oops.  Didn't actually drop the Cc on prior email.

Curtis

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

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

[Curtis Villamizar]

In message <54f26a38.8070...@gmail.com>
Brian E Carpenter writes:
 
> Admittedly 6renum was targetted at enterprise networks, partly because
> of the observation that homenets renumber anyway after every power
> cut. But we have spent a lot of cycles on this issue.
>  
> http://tools.ietf.org/html/rfc4192
> http://tools.ietf.org/html/rfc5887
> http://tools.ietf.org/html/rfc6866
> http://tools.ietf.org/html/rfc6879
> http://tools.ietf.org/html/rfc7010
> and maybe it's time to revive
> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
>  
>Brian


Hi Brian,

I'm sort of vaguely aware of this stuff on renumbering and of course
you are an author of much of it.  Some comments on this.

btw- this thread is almost certainly on the wrong WG mailing list so
if you'd like to redirect it, that would be a good thing for homenet.
It seems to be entirely enterprise renumbering focused.  Therefore
I've dropped the WG from the Cc for now.

The opsarea-ipv6-renumbering-guidelines draft seems like a bad
starting point.

For one thing the advice is change DNS first (break everything) and
then renumber.  No mention of dropping TTL to the minimum first which
would be less bad, but still bad (minimum 15 minute outage).

Oh wait ... that is essentially the topic of RFC 4192.  Just cite RFC
4192.

If it is a provider or enterprise renumber, then two prefixes are
available.  First add aliases allowing everything to be reachable
using either the old or new address.  Test.  Then change DNS.  Retest.
Then long after DNS caches have the new entry, drop the old addresses.
Retest should not be necessary but retest anyway.

Don't bother with ULAs unless there is no way to get a globally
routeable address.

Both routers and hosts with modern operating systems support numbering
the loopback.  These usually also support configuring the IPv6
preference to make binding to the loopback preferred without the
source code changes that used to be required in IPv4 years of old.

Perhaps RFC 2894 is a candidate for historic.

It is much easier to use RA and advertise the old prefix with a
prefered lifetime of zero.  Not that routers today take advantage of
either AFAIK.

RFC 5887 mentions both using RA and using DHCPv6 FORCERENEW or
RECONFIGURE for renumbering.

Is the use of RA M bit with no prefix or O bit with prefix still
considered ambiguous?

nit: Does anything really have a 128 bit DIP switch to set IPv6
address as implied in RFC 5887?  Certainly configured in
flash exists, but DIP switch.

In RFC 5887 section 7.  There is no need for address lifetimes in the
socket API if applications don't use bind to set the source address.

RFC 5887 7.1 :

FORCERENEW in particular requires DHCP authentication [RFC3118] to
be deployed.

Really?  I can see why since it could be used in a DoS attack if the
host didn't rate limit renewals.  But if it did rate limit renewal ...

In RFC 5887 7.2 - ISPs have figured out how to renumber.  Most already
generate configurations and push them out automatically even if that
means using a variety of "proprietary methods" (CLI).  And yes,
netconf is a good starting point but there may only be a problem for
small routers and/or smaller deployments that still hand configure.

I'm not sure that RFC 6866 and RFC 6879 add much value.

RFC 7010 does add value but IMHO not much.

Perhaps the emphasis should not be on "network renumbering is hard"
encouraging further whining.  The emphasis should not be on "network
renumbering does not need to be hard but can be very hard if certain
bad network management practices are followed".  First keep track of
everything that is configured, save the configuration, and know how to
reach that device to reconfigure it.  This includes DHCP servers.

  

For example, even for my home net I have a SVN controlled directory
known as system-files.  It has every configuration file
(boot/loader.conf, /etc/fstabs, /etc/rc.conf, /etc/mail/*, dhcpd.conf,
rtadvd.conf, etc).  It also has shell scripts for anything supporting
an automatable access to configs to compare the running config files
on a host to the stored ones or to update the config.  Renumbering was
a breeze - update all configs, mostly with emacs macros, then push out
new configs.  I did not have the luxury of a transition period but I
used the old addresses while updating and making the transition to the
new addresses.

I set this up this way because I had worked for an ISP and know that
if they had 2,000 things and didn't know where they were, what configs
they were running, or how to change them remotely, they would have
never survived.  Not everyone running an enterprise network has the
benefit of that prior experience.  And we certainly can't expect
anyone in a homenet to ever do this which is a big part of why we are
here.  And yes, all my rackmount servers and VMs and jails and desktop
are static configured.  Nothing is dynamic except those things
connecting on WiFi, where configs (where applicabl

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

[Brian E Carpenter]

Admittedly 6renum was targetted at enterprise networks, partly because
of the
observation that homenets renumber anyway after every power cut. But
we have spent a lot of cycles on this issue.

http://tools.ietf.org/html/rfc4192
http://tools.ietf.org/html/rfc5887
http://tools.ietf.org/html/rfc6866
http://tools.ietf.org/html/rfc6879
http://tools.ietf.org/html/rfc7010
and maybe it's time to revive
https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines

   Brian


On 01/03/2015 12:40, Curtis Villamizar wrote:
> In message 
> 
> Dave Taht writes:
>  
>> On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
>>  wrote:
>>> In message <54ee258e.8060...@gmail.com>
>>> Brian E Carpenter writes:
>>>
 On 26/02/2015 05:14, Mikael Abrahamsson wrote:
> On Wed, 25 Feb 2015, Ray Hunter wrote:
>
>> That way the devices can roam at L3, without all of the nasty side 
>> effects of re-establishing TPC sessions, or updating
>> dynamic naming services, or having to run an L2 overlay network 
>> everywhere, or having to support protocols that require a
>> specialised partner in crime on the server side (mTCP, shim6 et al).
>
> It's my firm belief that we need to rid clients of IP address dependence 
> for its sessions. Asking clients to participate in HNCP
> only addresses the problem where HNCP is used.
>
> Fixing this for real would reap benefits for devices moving between any 
> kind of network, multiple providers, mobile/fixed etc.

 Violent agreement. This is not a homenet problem; it's an IP problem.
 In fact, it's exactly why IP addresses are considered harmful in
 some quarters. Trying to fix it just for homenet seems pointless.
 http://www.sigcomm.org/ccr/papers/2014/April/000.008

Brian
>>>
>>>
>>> Brian,
>>>
>>> Seriously - your paper may be overstating the problem.  At least if we
>>> discount IPv4 and in doing so eliminate NAT we solve a lot of problems
>>> that never should have existed in the first place.  If we carry NAT
>>> over to IPV6, then shame on us.
>>  
>> I am sorry, I no longer share this opinion. The pains of renumbering
>> someones entire home network every time the ISP feels like it, given
>> the enormous number of devices I have encountered that don't handle it
>> well, are just too much to bear.
> 
> I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to
> ANSNET as part of the NSFNET decommissioning).  Not by myself of
> course, but there were only a few of us on this.  It wasn't all that
> bad and we had about 2,000 things to renumber in hundreds of
> locations, many of them not manned.  Shell scripts and ksh (kerberized
> rsh, not the Korn shell) made it simpler.  The worst was Cisco routers
> and various old DSU/CSU and other commercial stuff since you had to
> use "expect" scripts on their CLI rather than just something of the
> form "ksh fqdn -l root ifconfig newaddr/mask alias" People with root
> on their workstation that didn't give us acess were given notice.  We
> used interface aliases and gradually took down the old aliases and
> subnet addresses.  Nothing critical was affected.  It took a day or
> two, then bake time, then less than a day to remove aliases.
> 
> OTOH - Most homes can't run two prefixes for a week or two before
> taking the old prefix down.  And lots of consumer devices don't do
> aliases.  But now days there is DHCP which didn't exist then (and
> ICMPv6 RS/RA and SLAAC).
> 
> Are you having problems with the provider not giving you a static IPv6
> prefix, but rather changing it on a whim?
> 
> I also renumbered my home net multiple times, but again, not much
> pain.  Only a few consumer gadgets here have fixed addresses (one
> because it never renewed DHCP leases and therefore needed a fixed
> address, but that has since been tossed in e-waste recycling).
> 
>> The next version of cerowrt will do translation from the external IPv6
>> address range to a static internal one (or ones, in the case of
>> multiple egress gateways), and lacking a standard for such will use
>> fcxx/8 addressing. I will make it be an option for people to turn off,
>> but I've had it with being renumbered.
> 
> Are you suggesting that we add NAT to IPv6?  [I ask with disbelief.]
> 
> I would definitely be turning that off since I have a plenty big and
> very static IPv6 prefix.  I also have a (tiny) static IPv4 prefix so I
> have no choice but to IPv4 NAT due to its tiny size.
> 
> A better option might be to use something that switches over faster
> than a DHCP lease times of days.  It seems that ICMPv6 RA can be sent
> with prefix prefix information TLV with valid lifetime and/or
> preferred valid lifetime of zero.  This is in RFC 4861 on Page 55:
> 
>   - If the prefix is already present in the host's Prefix List as
> the result of a previously received advertisement, reset its
> invalidation timer to the Valid Lifetime value in the Prefix
>