Subject: Re: [v6ops] Documentation Prefixes for ULA

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Apr 2013 15:00:29 +0000

FWIW, I don't think we need to be overly worried about overlap
of the proposed document prefix (fc00:2001:db8::/48) with prefixes
that might occur in actual isolated networks. I use the prefix
2001:db8::/32 all the time when I set up isolated test networks,
and the implementations I have been using treat the addresses the
same as for any IPv6 GUA. It's just that that prefix should never
be injected into the public routing system, i.e., the same as
for fc00::/8.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush
> Sent: Saturday, March 30, 2013 1:51 AM
> To: Brian E Carpenter
> Cc: IETF v6ops list
> Subject: Re: [v6ops] Documentation Prefixes for ULA
> 
> >> Since it has come up, is there any interest in moving forward some
> >> from of ULA-C?
> > I don't see why. Although it could be automated, there is a cost
> > involved in any form of guaranteed uniqueness
> 
> we could have internet registry or registries keep track of assignments.
> ;~>
> 
> randy
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Apr 2013 15:44:47 +0000

> I am talking without tunnels.
> 
> One wouldnt want two vehicles nearby to go first through their VPN
> Gateways in Enterprise.
> 
> > Suggest you check out: NHRP, SSL, GRE, IPSec tunnel mode .....
> 
> Yes, and protocol Mobile IP.  All lack optimal routes - all go through
> anchor points, triangular routing, and multi-angular routing in case of
> moving networks.

IRON (and its component tunneling technologies AERO, SEAL and VET)
support route optimization.

Thanks - Fred

---

From: "Ivan Pepelnjak" <[email-masked]>
Date: Mon, 1 Apr 2013 18:37:14 +0200

This looks to me like "we need to agree on which subnet from 10/8 to use in documentation"

> Templin, Fred L
> Sent: Monday, April 01, 2013 5:00 PM
> To: Randy Bush; Brian E Carpenter
> Cc: IETF v6ops list
> FWIW, I don't think we need to be overly worried about overlap of the
> proposed document prefix (fc00:2001:db8::/48) with prefixes that might
> occur in actual isolated networks. I use the prefix
> 2001:db8::/32 all the time when I set up isolated test networks, and the
> implementations I have been using treat the addresses the same as for any
> IPv6 GUA. It's just that that prefix should never be injected into the
> public routing system, i.e., the same as for fc00::/8.
> 
> Thanks - Fred
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Randy Bush

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Apr 2013 19:02:18 +0200

Le 01/04/2013 17:00, Templin, Fred L a écrit :
> proposed document prefix (fc00:2001:db8::/48) with prefixes that
> might occur in actual isolated networks.

Ok.

> I use the prefix 2001:db8::/32 all the time when I set up isolated
> test networks, and the implementations I have been using treat the
> addresses the same as for any IPv6 GUA. It's just that that prefix
> should never be injected into the public routing system, i.e., the
> same as for fc00::/8.

Fred.

Also at where I do small isolated networks we often set up such small 
networks with 2001:db8::.  It's very handy.

However, I am not sure whether this is the right thing I do...

Maybe the RFC says somewhere that the Documentation prefix is only to be 
put on paper?  I dont know, maybe it doesnt.

But, the worst, is that the act of doing so - set up now a small network 
with 2001:db8:: - is actually a commitment to renumber when I connect 
that small network to another small network (both disconnected from the 
Internet).

I have seen so many such small networks, they all start with first 
subnet having 2001:db8:1::/64, second 2, and so on.  Then there is also 
this "dead:beef", "face:booc" and so on.  I think I've seen collisions 
for many.  It's still small, so no important problem to talk about - 
these are small networks.

This is just a comment.

Alex

>
> Thanks - Fred [email-masked]
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Randy Bush Sent:
>> Saturday, March 30, 2013 1:51 AM To: Brian E Carpenter Cc: IETF
>> v6ops list Subject: Re: [v6ops] Documentation Prefixes for ULA
>>
>>>> Since it has come up, is there any interest in moving forward
>>>> some from of ULA-C?
>> we could have internet registry or registries keep track of
>> assignments. ;~>
>>
>> randy _______________________________________________ v6ops mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Apr 2013 19:45:27 +0200

On 1 apr 2013, at 19:02, Alexandru Petrescu <[email-masked]> wrote:

>> test networks

> Also at where I do small isolated networks we often set up such small networks with 2001:db8::.  It's very handy.

Wouldn't using ULAs for this be even more handy?

Iljitsch

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Apr 2013 20:31:55 +0200

> Wouldn't using ULAs for this be even more handy?

It would!

If only I had an implementation at hand that generated ULA prefixes... 
something like:

# generate-ula --local eth0
fd00:3124:AFE3::/64, press CR for more, or Ctrol-D to quit.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Apr 2013 14:48:14 +0100

> put on paper?  I dont know, maybe it doesnt.

The point is that IANA will never allocate the documentation prefixes,
so they will never be routed, even if used for testing purposes.
The same is true for the documentation domains like example.com.

But this argument doesn't apply to ULAs (or RFC 1918s) since they will
never be routed.

Also, the ID checklist (http://www.ietf.org/id-info/checklist.html)
says: "Private addresses that would be used in the real world SHOULD
be avoided in examples." iirc, it's a SHOULD precisely because sometimes
it's essential to give RFC 1918 or ULA examples.

I think my conclusion is that we don't need to do anything.

    Brian

---

From: "cb.list6" <[email-masked]>
Date: Tue, 2 Apr 2013 06:53:32 -0700

Sent from ipv6-only Android
On Apr 2, 2013 6:48 AM, "Brian E Carpenter" <[email-masked]>
> I think my conclusion is that we don't need to do anything.

+1. No need for ULA doc prefix.

Random numbers are random and large numbers are large.

CB

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Apr 2013 16:34:16 +0200

> I think my conclusion is that we don't need to do anything.

In a sense I could agree towards not reserving 'documentation' ULA 
because it would risk loss of some address space.

The explanation effort about ULAs is there simply to help continuing the 
convenience of using them.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Apr 2013 20:23:16 +0200

> support route optimization.

That is good to know.  We could discuss that if there is interest. 
There are a number of other draft proposals about this as well.

And 2 RFCs with problem statement and analysis of solution space.

Alex