Subject: [v6ops] ULA discussion #BCP or Informational

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 26 Mar 2013 11:56:22 +0000

Hi, Dear all

[Note: You can also raise some topic you consider as important with the prefix "ULA discussion #", so that the future discussion could be easily tracked. Thank you.]

This post is regarding the document should be a "BCP" or "Informational". 
Personally, either BCP or Informational is OK for me. But I'd like to discuss it in the perspective of the document.

I checked RFC2026 (The Internet Standards Process -- Revision 3), in section 5, the BCP document is described as "a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function."

So, I believe it is a good goal to publish the ULA draft as a BCP, I think the position is valuable for the readers. However, some texts (especially NAT relative) are still controversy that might not be consensus of representing "the community's best current thinking". But let's try to find the common view/principle out of the controversy materials, if not applicable, then it is OK to be Informational.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Mar 2013 22:52:29 +0900

Informational.

The way I see it, the scenarios in this document are not current practice,
because they are not currently deployed to any substantial degree. And if
this document is not current practice, then it cannot be Best Current
Practice.
On 26 Mar 2013 20:56, "Liubing (Leo)" <[email-masked]> wrote:

> Hi, Dear all
>
> [Note: You can also raise some topic you consider as important with the
> prefix "ULA discussion #", so that the future discussion could be easily
> tracked. Thank you.]
>
> Personally, either BCP or Informational is OK for me. But I'd like to
> discuss it in the perspective of the document.
>
> I checked RFC2026 (The Internet Standards Process -- Revision 3), in
> section 5, the BCP document is described as "a vehicle by which the IETF
> community can define and ratify the community's best current thinking on a
> statement of principle or on what is believed to be the best way to perform
> some operations or IETF process function."
>
> So, I believe it is a good goal to publish the ULA draft as a BCP, I think
> the position is valuable for the readers. However, some texts (especially
> NAT relative) are still controversy that might not be consensus of
> representing "the community's best current thinking". But let's try to find
> the common view/principle out of the controversy materials, if not
> applicable, then it is OK to be Informational.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "cb.list6" <[email-masked]>
Date: Tue, 26 Mar 2013 07:00:13 -0700

On Mar 26, 2013 6:52 AM, "Lorenzo Colitti" <[email-masked]> wrote:
>
> Informational.
>
> The way I see it, the scenarios in this document are not current
practice, because they are not currently deployed to any substantial
degree. And if this document is not current practice, then it cannot be
Best Current Practice.

What does substantial degree mean ?

I have ULAs deployed at several places in my network consistent with the
draft.

I too am fine with informational status, but these ideas have been applied.

Cameron

>>
>> So, I believe it is a good goal to publish the ULA draft as a BCP, I
think the position is valuable for the readers. However, some texts
(especially NAT relative) are still controversy that might not be consensus
of representing "the community's best current thinking". But let's try to
find the common view/principle out of the controversy materials, if not
applicable, then it is OK to be Informational.

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Mar 2013 18:12:48 +0000

On 26 Mar 2013, at 14:00, cb.list6 <[email-masked]> wrote:
> > The way I see it, the scenarios in this document are not current practice, because they are not currently deployed to any substantial degree. And if this document is not current practice, then it cannot be Best Current Practice.
> >
> 
> I have ULAs deployed at several places in my network consistent with the draft.
> 

I think Informational.

If RFC4890 is Informational, then this certainly is.

Like 4890, it could be upgraded in due course.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 27 Mar 2013 10:45:47 +0900

> What does substantial degree mean ?
"Deployments in multiple different networks of each of the scenarios in the
draft" would be a minimum requirement, I'd think.

> I too am fine with informational status, but these ideas have been applied.
Which ones? All of them?

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 27 Mar 2013 12:40:12 +0900

Informational.
And it should investigate more detail.

Regards,
-Shishio

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Mar 2013 15:14:54 +0900

BOP == bad occasional practice

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Mar 2013 08:33:44 +0000

I think we have a much better chance of reaching consensus with
Informational status, because it limits the content to description
of scenarios that are expected to work, and removes endless arguments
about whether we recommend any of those scenarios.

Regards
   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 27 Mar 2013 08:50:15 +0000

>about whether we recommend any of those scenarios.

Agree. It is better to start as Informational, giving that there are still a lot uncertainness for recommendations. If in the developing process of this document, the community reaches consensus on all recommendation or guidance, it may be upgraded.

Regards,

Sheng

>prefix "ULA discussion #", so that the future discussion could be easily tracked.
>Thank you.]
>>
>> I checked RFC2026 (The Internet Standards Process -- Revision 3), in section
>5, the BCP document is described as "a vehicle by which the IETF community
>can define and ratify the community's best current thinking on a statement of
>principle or on what is believed to be the best way to perform some
>operations or IETF process function."
>>
>> So, I believe it is a good goal to publish the ULA draft as a BCP, I think the
>position is valuable for the readers. However, some texts (especially NAT
>relative) are still controversy that might not be consensus of representing "the
>community's best current thinking". But let's try to find the common
>view/principle out of the controversy materials, if not applicable, then it is OK
>to be Informational.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 27 Mar 2013 08:05:48 -0400

> The way I see it, the scenarios in this document are not current practice,
because they are not currently deployed to any substantial degree. And if this
document is not current practice, then it cannot be Best Current Practice.

>Cameron

I also think Informational is the correct status of this document.  As noted
before, although some of us have used ULAs for legitimate reasons which
align with some parts of the draft, perhaps BCP is a bit pre-mature.  I say
this since there may be some of the scenarios which have not had much time
in production.

Victor K

---

From: Arturo Servin <[email-masked]>
Date: Wed, 27 Mar 2013 09:16:27 -0300

Informational.

Regards
as

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Mar 2013 20:42:08 +0100

I tend to agree with the status INFORMATIONAL because it is the least
conflictual as I read recently.  So, number 0 - yes I agree INFORMATIONAL.

Also, the BCP makes me think of a large deployment experience, which
doesnt seem to be the case here.   BCP also makes me think of an old
very old deployment about which we could discuss but couldnt make any
suggestion for improvement because few care anylonger.

For example FTP directory listing is BCP, but IPv6 RFC2460 is not BCP.

Alex

----------------------------------------------------------------------

Then, if place is left for discussion, and if disagreements to below
dont risk the INFORMATIONAL status as suggested above, here are some
other comments.

I think it is good to go towards a practice like this:

- don't write ULAs like this: fd::1, because it's not an ULA.  The ULA
   must start with fd00: and not fd:, because whereas the leading 0s can
   be ommitted the subsequent 0s are significant, in this Western-
   inspired textual address representation system (like 003 dollars is
   same value as 3 dollars, but 300 dollars is not the same as 3
   dollars).

- don't write example ULAs like this: fd00::1 because there seems to be
   only 0s between fd and 1, whereas a real ULA has randomness in that
   space, to ensure uniqueness.  fd00:face:booc::1 is probably a better
   ULA although a trained eye may notice a surprising coincidence hard
   to generate randomly.

- dont assign fd00::1/128 address on the default Gateway, even though
   one is used to assign such in IPv4; the reason same as above - lack
   of randomnes.

- if you want to set up a small network which has multiple subnets, and
   you can't get IPv6 global unicast addresses from an authority or an
   authoritative sysadmin (prefixed by 001 first three bits), like a
   Provider Independepent, or Provider Assigned addresses - then use
   ULAs to configure your small network.

- for that small network use ULAs rather than making up some global
   unicast addresses out of a prefix which was not previously guaranteed
   unique by the administration.

- dont use 2001:db8:: prefix to assign to that small network - it's a
   Documentation prefix, has sense for humans but not for computers.
   Rather use ULAs, or global unicast addresses if you can get some.

- dont use ULA with NAT - it doesnt work.

Alex

Le 26/03/2013 12:56, Liubing (Leo) a écrit :
> Hi, Dear all
>
> [Note: You can also raise some topic you consider as important with
> the prefix "ULA discussion #", so that the future discussion could
> be easily tracked. Thank you.]
>
> This post is regarding the document should be a "BCP" or
> "Informational". Personally, either BCP or Informational is OK for
> me. But I'd like to discuss it in the perspective of the document.
>
> section 5, the BCP document is described as "a vehicle by which the
> IETF community can define and ratify the community's best current
> thinking on a statement of principle or on what is believed to be
> the best way to perform some operations or IETF process function."
>
> (especially NAT relative) are still controversy that might not be
> consensus of representing "the community's best current thinking".
> But let's try to find the common view/principle out of the
> controversy materials, if not applicable, then it is OK to be
> Informational. _______________________________________________ v6ops
> mailing list [email-masked]

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 28 Mar 2013 03:18:54 +0000

Hi, Alex

Thanks for the detailed suggestion, they are good operational concerns. Right now I haven't figured out whether to include these fine granularity considerations into the general guidance. But I'll consider them in the next version.

Some other replies inline as below.

>    same value as 3 dollars, but 300 dollars is not the same as 3

[Bing] I think fc00:/7 might be more accurate? Although most of the time it would be fd00:/8, but maybe it is not necessarily to exclude L=0. 

> - dont use ULA with NAT - it doesnt work.

[Bing] Well, this is the big issue I need to address in the next version: )   
According to the discussions, I prefer NOT explicitly recommend against ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some operational concerns/warning as well. And I'll separate the NPTv6 with NAPT, and limit the scope within NPTv6, because it is the only IPv6 NAT related standard available so far.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 21:53:59 -0700

> [Bing] I think fc00:/7 might be more accurate? Although most of the time it would be fd00:/8, but maybe it is not necessarily to exclude L=0. 

There is no valid use of L=0 currently. The IETF did not gain consensus for
that draft and no substitute proposal has emerged or shown any signs of
gaining consensus. IIRC, it was slightly more controversial than the idea of
routing information in DHCP.

>>   ULA although a trained eye may notice a surprising coincidence hard

Actually, I would recommend that we use fd00:2001:db8::/48 as the example
ULA. I will submit a draft for that update to the Example Prefix RFC.

>>   of randomness.

True, but there's nothing wrong with establishing an example ULA prefix
at fd00:2001:db8::/48 and then using fd00:2001:db8::/64 as the first
prefix in that /48 and fd00:2001:db8::1/128 as the gateway address for
that /64.

>>   ULAs to configure your small network.

Why would you be unable to get such address space? To the best of my
knowledge, all of the RIRs have provisions for granting addresses to
non-connected networks.

>>   unique by the administration.

ULA is definitely preferable to squatting on bosons, but much in the same
way that the flu is preferable to cancer.

>>   Rather use ULAs, or global unicast addresses if you can get some.

Agreed… This should be in the document. Especially if we use the
example prefix of fd00:2001:db8::/48 as our example ULA.

> According to the discussions, I prefer NOT explicitly recommend against ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some operational concerns/warning as well. And I'll separate the NP…

I would strongly urge you to recommend against NAT.

NAT is just too expensive and too destructive to the internet in general. There is no valid reason not to recommend against it.

However, a statement that it "does not work" would be inappropriate. For better or worse (and I believe mostly worse), it does actually work. It just has very harmful side effects while it works.

Owen

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 28 Mar 2013 06:23:28 +0000

Hi, Owen

Thanks for your comments. Please see inline.

Best regards,
Bing

> > [Bing] I think fc00:/7 might be more accurate? Although most of the time it
> would be fd00:/8, but maybe it is not necessarily to exclude L=0.
> 

[Bing] I understand the L=0 situation. But is it necessary to exclude it? In another word, is fc00:/7 harmful? 
My concern is that the fc00::/7 form is more compliance to the definition in RFC4193.

> ULA. I will submit a draft for that update to the Example Prefix RFC.

[Bing] I'm not very sure, 2001:db8 is a typical GUA form, will it lead some confusion about randomness?

> knowledge, all of the RIRs have provisions for granting addresses to

[Bing] I guess Alex was talking about some situations lack of money/conditions to apply address space from RIRs/LIRs. 

> Agreed... This should be in the document. Especially if we use the
> > According to the discussions, I prefer NOT explicitly recommend against
> ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some
> operational concerns/warning as well. And I'll separate the NPTv6 with NAPT,
> and limit the scope within NPTv6, because it is the only IPv6 NAT related
> standard available so far.
> 
> NAT is just too expensive and too destructive to the internet in general.
> There is no valid reason not to recommend against it.

[Bing] A valid reason as I can tell is, when you want independent address space and you cannot or do not want to afford the cost of PI (thinking about SOHO/SMEs).
Since this topic is the controversy focus, later I'll raise another separated thread to talk about what could be possibly consensus.

> 
> However, a statement that it "does not work" would be inappropriate. 
[Bing] Agreed.

>For better or worse (and I believe mostly worse), it does actually work. It just has
> very harmful side effects while it works.
> 
> Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Mar 2013 18:14:04 +0100

> routing information in DHCP.

Ok, the RFC says "L==0 may be defined in the future" ; probably we're 
not yet there.

> ULA. I will submit a draft for that update to the Example Prefix RFC.

Sounds a reasonable idea to say fd00:2001:db8::/48 to be the 
Documentation ULA.  I am interested if a draft gets written, it could be 
very short.

At the same time, I wonder how much right are we to agree that a real 
ULA is always FD00::something.  I mean the presence of these two 00 digits.

I mean it is also correct to say that this is a ULA prefix:

             FD79:0D81:183C:D1A0::/59

Right?

(for information this is generated using the ULA RFC suggested method in 
section 3.2.2, but using the VIN VF2R97K9XN87R9869 instead of an EUI-64 
(because we didnt know _which_ EUI-64 of the vehicle to use).

> prefix in that /48 and fd00:2001:db8::1/128 as the gateway address for

Right.

> knowledge, all of the RIRs have provisions for granting addresses to

I have never tried to ask RIRs directly but I have doubts.

In the past I usually asked the operator of the Internet line (T1, E2, 
etc.) to provide me IPv4 Class C or better - I had to insist and spend 
time to get Class C.

I thought that an end user (like a vehicle manufacturer) would not be in 
a position to ask RIR directly.

I guess it could cost a lot of money to ask for as many IPv6 subnets as 
VIN offers to that manufacturer.

Do you mean that a person like in my position (I am not an ISP, nor a 
IXP) could ask RIR for e.g. a 61bit space? (i.e. asking a /3 prefix)? 
(sorry I bring vehicle in the picture, just to illustrate one particular 
need for ULAs that I think will grow - one single vehicle manufacturer 
by definition and without paying has the right to VIN space which 
roughly translates into 61bit space).

> way that the flu is preferable to cancer.

Well, I would be careful with the first statement.  I am not sure there 
are enough IPv6 prefixes available to put one on each boson (if that 
boson had Interface ID of length 64).

> example prefix of fd00:2001:db8::/48 as our example ULA.

The ULA Documentation prefix is a good idea.  It allows people to talk 
about it meaningfully.

> For better or worse (and I believe mostly worse), it does actually
> work.

The situation could be improved.  I think it would be easy to locate the 
ip6tables MASQUERADE C code and add a if condition by which if ULA then 
don't rewrite.  Then submit to kernel maintainers and suggest inclusion 
in mainline.

It's the same as with link-local addressees - packets whose src/dst are 
such dont get forwarded, by a simple rule in the C code, in agreement 
with RFC.

Alex

> It just has very harmful side effects while it works.
>
> Owen
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Mar 2013 18:17:39 +0100

Le 28/03/2013 07:23, Liubing (Leo) a écrit :
> Best regards, Bing
>>>> - don't write ULAs like this: fd::1, because it's not an ULA.
>>>> The ULA must start with fd00: and not fd:, because whereas the
>>>> leading 0s can be ommitted the subsequent 0s are significant,
>>>> in this Western- inspired textual address representation system
>>>> (like 003 dollars is same value as 3 dollars, but 300 dollars
>>>> is not the same as 3 dollars).
>>>
>> There is no valid use of L=0 currently. The IETF did not gain
>> consensus for that draft and no substitute proposal has emerged or
>> shown any signs of gaining consensus. IIRC, it was slightly more
>> controversial than the idea of routing information in DHCP.
>
> [Bing] I understand the L=0 situation. But is it necessary to exclude
> it? In another word, is fc00:/7 harmful? My concern is that the
> fc00::/7 form is more compliance to the definition in RFC4193.

Right...

>>>> - don't write example ULAs like this: fd00::1 because there
>>>> seems to be only 0s between fd and 1, whereas a real ULA has
>>>> randomness in that space, to ensure uniqueness.
>>>> fd00:face:booc::1 is probably a better ULA although a trained
>>>> eye may notice a surprising coincidence hard to generate
>>>> randomly.
>>
>> Actually, I would recommend that we use fd00:2001:db8::/48 as the
>> example ULA. I will submit a draft for that update to the Example
>> Prefix RFC.
>

Hm.  But we'd still need a means to talk example ULAs, draw on a board, etc.

I wouldn't draw something that says 2001:db8:: is a ULA.

>>>> - dont assign fd00::1/128 address on the default Gateway, even
>>>> though one is used to assign such in IPv4; the reason same as
>>>> above - lack of randomness.
>>
>> True, but there's nothing wrong with establishing an example ULA
>> prefix at fd00:2001:db8::/48 and then using fd00:2001:db8::/64 as
>> the first prefix in that /48 and fd00:2001:db8::1/128 as the
>> gateway address for that /64.
>>
>>>> - if you want to set up a small network which has multiple
>>>> subnets, and you can't get IPv6 global unicast addresses from
>>>> an authority or an authoritative sysadmin (prefixed by 001
>>>> first three bits), like a Provider Independepent, or Provider
>>>> Assigned addresses - then use ULAs to configure your small
>>>> network.
>>
>> Why would you be unable to get such address space? To the best of
>> my knowledge, all of the RIRs have provisions for granting
>> addresses to non-connected networks.
>
> [Bing] I guess Alex was talking about some situations lack of
> money/conditions to apply address space from RIRs/LIRs.

Lack of knowledge also.

I dont know which RIRs/LIRs should I ask?  Do they have a formal procedure?

Does it cost a lot of money?

How much maximum could I get if I were a vehicle manufacturer?

Alex

>>>> - for that small network use ULAs rather than making up some
>>>> global unicast addresses out of a prefix which was not
>>>> previously guaranteed unique by the administration.
>>
>> ULA is definitely preferable to squatting on bosons, but much in
>> the same way that the flu is preferable to cancer.
>>
>>>> - dont use 2001:db8:: prefix to assign to that small network -
>>>> it's a Documentation prefix, has sense for humans but not for
>>>> computers. Rather use ULAs, or global unicast addresses if you
>>>> can get some.
>>
>>> [Bing] Well, this is the big issue I need to address in the next
>>> version: ) According to the discussions, I prefer NOT explicitly
>>> recommend against
>> operational concerns/warning as well. And I'll separate the NPTv6
>> with NAPT, and limit the scope within NPTv6, because it is the only
>> IPv6 NAT related standard available so far.
>>
>> NAT is just too expensive and too destructive to the internet in
>> general. There is no valid reason not to recommend against it.
>
> [Bing] A valid reason as I can tell is, when you want independent
> address space and you cannot or do not want to afford the cost of PI
> (thinking about SOHO/SMEs). Since this topic is the controversy
> focus, later I'll raise another separated thread to talk about what
> could be possibly consensus.
>
>>
>> work. It just has very harmful side effects while it works.
>>
>> Owen
>
>
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 10:58:08 -0700

> My concern is that the fc00::/7 form is more compliance to the definition in RFC4193.

I don't object to including fc00::/7 so long as it is made clear that:

"Though we document fc00::/7 here as compliant with RFC4193, at the time of writing, there is no
documented legitimate use for fc00::/8 (L=0) and only addresses within fd00::/8 have a valid
documented use. The draft for the original intent of fc00::/8 expired without consensus."

> [Bing] I'm not very sure, 2001:db8 is a typical GUA form, will it lead some confusion about randomness?

I think it's just about as random as any other example you could use. At least
if someone mistakenly configures that following the examples, it's a clear case
of misconfiguration by example.

There is only so much we can do to help the illiterate to read the RFC.

> [Bing] I guess Alex was talking about some situations lack of money/conditions to apply address space from RIRs/LIRs. 

The RIR policies have been rather stingy in the IPv4 world, but to the best of my knowledge, each of the RIRs has pretty liberal policies WRT getting IPv6 addresses. The monetary issue is a separate problem and is really outside of the scope of IETF.

> Since this topic is the controversy focus, later I'll raise another separated thread to talk about what could be possibly consensus.

I run a SOHO... I have PI v4 and v6. Currently I pay $100/year for my PI space. Shortly that will jump to $300/year ($200 for my IPv4 and $100 for my IPv6).

I consult for several SMEs and have installed PI v4 and v6 solutions for them. The cost of the IP space has been a trivial portion of the overall expense of their network deployments.

Even if you choose to use ULA for stable internal addressing, there is still no valid reason not to use PA or PI space for your external connectivity. All hosts in IPv6 are required to support multiple addresses per interface. Bare bones connectivity off the local subnet requires at least two addresses (link local and some form of global scoped address, whether that's a ULA global scoped address or a GUA global scoped address or something else we invent later).

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Mar 2013 19:26:54 +0100

Le 29/03/2013 18:58, Owen DeLong a écrit :
[...]
> The RIR policies have been rather stingy in the IPv4 world, but to
> the best of my knowledge, each of the RIRs has pretty liberal
> policies WRT getting IPv6 addresses. The monetary issue is a separate
> problem and is really outside of the scope of IETF.

I checked some RIR conditions about allocating PI space.

Other than the price tag (I don't know) there is a set of other
administrative and technical requirements which make me doubt about its
adaptation to vehicular traits like mobility.

- RIR says only a maximum of /48 prefix can be allocated as PI, to end
   user.  I am not sure one /48 is enough for a vehicle manufacturer,
   because it would give only 2^16 /64 prefixes.  This is way too little
   for the number of vehicles manufactured by one manufacturer in 10
   years time.

   RIR says exceptions are possible, but then one has to go and
   motivate.

- RIR says that a contractual relationship must be developped between
   enduser and a LIR (Local...).  They dont say what happens when that
   vehicle manufacturer is itself also a LIR for its business offices,
   or for its other small fleet.

- it seems to me RIR also says that PI space may be allocated _only_
   within that LIR.  Whereas this may work with a LIR which is e.g.
   T-Mobile (it has presence in many countries where a vehicle
   would go), it may not work otherwise.

- there may be other aspects in that pdf that I didnt have time yet to
   read and understand.  I will look later.

All these things seem complicated.

It seems much easier just make ULAs and stamp them on vehicles.  Vehicle
manufacturers, insurers, government are all used to stamp unique numbers
on vehicles - the VIN, the engine number, insurance ids, license plate, etc.

Of course - state they dont reach the Internet.  If Internet
car-to-cloud application is needed then use PI or PA addressing space,
not ULA.  But ULA may be sufficient for numerous in-vehicle
applications, or even vehicle-to-vehicle applications (without
infrastructure).

>>>>> - dont use 2001:db8:: prefix to assign to that small network
>>>>>  - it's a Documentation prefix, has sense for humans but not
>>>>>  for computers. Rather use ULAs, or global unicast addresses
>>>>>  if you can get some.
>>>
>>> Agreed... This should be in the document. Especially if we use
>>> the example prefix of fd00:2001:db8::/48 as our example ULA.
>>>
>>>>
>>>>
>>>> [Bing] Well, this is the big issue I need to address in the
>>>> next version: ) According to the discussions, I prefer NOT
>>>> explicitly recommend against
>>> with NAPT, and limit the scope within NPTv6, because it is the
>>> only IPv6 NAT related standard available so far.
>>>
>> address space and you cannot or do not want to afford the cost of
>> PI (thinking about SOHO/SMEs). Since this topic is the controversy
>>  focus, later I'll raise another separated thread to talk about
>> what could be possibly consensus.
>
> I run a SOHO... I have PI v4 and v6. Currently I pay $100/year for my
> PI space. Shortly that will jump to $300/year ($200 for my IPv4 and
> $100 for my IPv6).
>
> I consult for several SMEs and have installed PI v4 and v6 solutions
>  for them. The cost of the IP space has been a trivial portion of the
>  overall expense of their network deployments.

Hmm... I tend to agree.  But depends where one looks at it from.  I
think in many fixed cases (like SOHO) the PI cost and usefulness make a
very good tradeoff, like suggested above.

> Even if you choose to use ULA for stable internal addressing, there
> is still no valid reason not to use PA or PI space for your external
>  connectivity.

Agreed.

> All hosts in IPv6 are required to support multiple addresses per
> interface. Bare bones connectivity off the local subnet requires at
> least two addresses (link local and some form of global scoped
> address,

(not to mention the Privacy Extensions addresses)

> whether that's a ULA global scoped address or a GUA global scoped
> address or something else we invent later).

I agree, multiple addresses on a single interface is the norm in IPv6
deployments (it was there in the very first IPv6 stacks), rather than
the exception as it is with IPv4.

Alex

---

From: joel jaeggli <[email-masked]>
Date: Fri, 29 Mar 2013 12:01:18 -0700

>   for the number of vehicles manufactured by one manufacturer in 10
Entirely aside the issue of whether you want to number cars out of pi or 
not, this is also nonsense.

You can see the arin direct assignment policy here:

https://www.arin.net/policy/nrpm.html#six58

My company with 11 current locations 5 of which were at time of request 
datacenters received a /44 under the  ARIN policy...

let's look elsewhere... (maybe you should ask these folks to come to the 
meeting in berlin, (they're not that far away) and talk about their 
assignment experience).

joels-MacBook-Air:~ jjaeggli$ whois -h whois.ripe.net 2a01:4dc0::/29
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '2a01:4dc0::/29'

inet6num:       2a01:4dc0::/29
netname:        DE-VOLKSWAGENAG-20120530
descr:          Volkswagen AG
country:        DE
org:            ORG-VA303-RIPE
admin-c:        VWAG1-RIPE
tech-c:         VWAG1-RIPE
status:         ALLOCATED-BY-RIR
mnt-by:         RIPE-NCC-HM-MNT
mnt-lower:      AB82394-MNT
mnt-routes:     AB82394-MNT
source:         RIPE # Filtered

organisation:   ORG-VA303-RIPE
org-name:       Volkswagen AG
org-type:       LIR
address:        Volkswagen AG
address:        Harald Berg Brieffach 1693
address:        Berliner Ring 2
address:        38436
address:        Wolfsburg
address:        GERMANY
phone:          +495361927082
fax-no:         +49536195727082
admin-c:        AB24611-RIPE
mnt-ref:        AB82394-MNT
tech-c:         VWAG1-RIPE
mnt-by:         RIPE-NCC-HM-MNT
source:         RIPE # Filtered

role:           VW AG Network Planning
address:        Berliner Ring 2
address:        38440 Wolfsburg
address:        Germany
org:            ORG-VA303-RIPE
admin-c:        VWAG1-RIPE
tech-c:         AB24611-RIPE
nic-hdl:        VWAG1-RIPE
mnt-by:         AB82394-MNT
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 
1.58.1 (WHOIS2)

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 12:21:48 -0700

I am considering submitting the following as an internet draft. I wanted to get feedback from folks on this list about it first. Ideally, I would like to see it adopted by this working group for publication as an informational RFC alongside RFC 3849.

Executive Summary: Designate fc00:2001:db8::/48 and fd00:2001:db8::/48 as additional documentation prefixes so that we have ULA prefix examples for use in documentation and training materials.

Any feedback is welcome, including nitpicks about formatting errors, grammar, etc. This is my first time writing an Internet Draft. I have attempted to incorporate the vast array of specifications, hints, and suggestions from the IETF website, but any help is appreciated.

Thanks,

Owen

======

Network Working Group                                          O. DeLong
Internet-Draft                                         DeLong Consulting
Category: Informational
                                                              March 2013

           ULA IPv6 Address Prefix Reserved for Documentation

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2013).

Abstract

   To reduce the likelihood of conflict and confusion when relating
   documented examples to deployed systems, an IPv6 Unicast Address
   prefix is reserved for use in examples in RFCs, books, documentation,
   and the like.

   Since the publication of [RFC 4193] (ULA), it is necessary to
   provide examples of ULA addresses in various documents, including
   some Internet-Drafts currently under consideration.

   This draft seeks to add fd00:2001:db8::/48 to the prefixes reserved
   for documentation purposes as is 2001:db8::/32 in [RFC 3849].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts. The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 29, 2013.

DeLong                       Informational                      [Page 1]
 
Internet-Draft         ULA Documentation Prefix               March 2013

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents.
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction.....................................................2
   2. Acknowledgements.................................................2
   3. Documentation IPv6 Unique Local Address Prefix...................3
   4. Operational Implications.........................................3
   5. IANA Considerations..............................................3
   6. Security Considerations..........................................3
   7. References.......................................................4
     7.1. Normative References.........................................4
     7.2. Informative References.......................................4
   Authors' Addresses..................................................4

1. Introduction

   [RFC 4193] does not specify a ULA prefix to be used for
   documentation purposes. For the same reasons an IPv6 Global
   Unicast Prefix (GUA) is needed for documentation in [RFC 3849],
   there is also need for a ULA prefix.

   Whereas [RFC 3849] delegates 2001:db8::/32 to be used for
   documentation purposes where an IPv6 GUA prefix or address
   is needed, this memo proposes designating two /48s from
   ULA space for that purpose when an example of ULA is needed.

2. Acknowledgements

   This draft is a logical extension of the work in [RFC 3849] and
   I wish to thank and acknowledge the contributions of its authors
   Geoff Huston, Anne Lord, and Phil Smith.

DeLong                       Informational                      [Page 2]
 
Internet-Draft         ULA Documentation Prefix               March 2013

3. Documentation IPv6 ULA Prefix

   To allow documentation to accurately describe deployment examples,
   the use of site local or link local addresses is inappropriate, and a
   unicast address block is required. While there is Global Unicast
   space designated for Documentation in [RFC 3849], no such provision
   exists within the ULA prefix (fc00::/7) for either random (fd000::/8)
   or registered (fc00::/8).

   Since 2001:db8::/32 was designated for documentation purposes in
   [RFC 3849] and is widely and readily recognized as such throughout
   the networking community, this memo suggests the use of similar
   ranges within the ULA prefixes for that same purpose. The proposed
   prefixes are fc00:2001:db8::/48 (ULA Registered) and
   fd00:2001:db8::/48 (ULA Random), respectively.

   In the case of fc00:2001:db8::/48 this would serve only as a
   statement of intent until such time as the use of fc00::/8 is
   documented by the IETF.

4.  Operational Implications

   This assignment implies that IPv6 network operators should not
   use these prefixes in their actual deployments of IPv6 ULA.

   Further it implies that these prefixes should be specifically
   filtered in any situation where overlapping ULA prefixes may be
   otherwise permitted by route or packet filters.

   This is not a local-use prefix, and the filters may be used in
   both local and public contexts, though in the public context, a
   more general filter of all ULA space (fc00::/7) may be more
   desirable. In general, the combination of the specific and more
   generic filter together should, while unnecessary, not have
   any harmful effects.

5.  IANA Considerations

   IANA is to record the allocation of the IPv6 ULA prefixes
   fc00:2001:db8::/48 and fd00:2001:db8::/48 as additional
   documentation-only prefixes in the IPv6 address registry.
   No end party is to be assigned these addresses.

6.  Security Considerations

   IPv6 addressing documents do not have any direct impact on Internet
   infrastructure security.

DeLong                       Informational                      [Page 3]
 
Internet-Draft         ULA Documentation Prefix               March 2013

7.  References
7.1.  Normative References
   [RFC3849] Huston, G., Lord, A., and Smith, P., "IPv6 Address Prefix
             Reserved for Documentation", RFC 3849, July 2004.

7.2.  Informative References
   [RFC4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast
             Addresses", RFC 4193, October 2005.

Authors' Addresses

   Owen DeLong
   DeLong Consulting

   EMail: [email-masked]

Full Copyright Statement

   Copyright (C) The Internet Society (2013).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

DeLong                       Informational                      [Page 3]
 
Internet-Draft         ULA Documentation Prefix               March 2013

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [email-masked].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 12:34:08 -0700

> Sounds a reasonable idea to say fd00:2001:db8::/48 to be the Documentation ULA.  I am interested if a draft gets written, it could be very short.
> 
> At the same time, I wonder how much right are we to agree that a real ULA is always FD00::something.  I mean the presence of these two 00 digits.
> 

It is not... It is fdxx:something.

> I mean it is also correct to say that this is a ULA prefix:

Yes.

However, when writing all-ULA as a prefix, it is one of fc00::/8 (ULA Global, not currently standardized), fd00::/8 (ULA Random, RFC4193), or fc00::/7 (ULA in general with L bit unspecified).

> I have never tried to ask RIRs directly but I have doubts.

I can't speak with certainty for all RIRs, but I know the ARIN policy well. I have been involved in writing all of the current IPv6 policy in ARIN and was the primary author of the current IPv6 ISP policy.

I am quite certain that you can apply to ARIN for a non-connected network.

> In the past I usually asked the operator of the Internet line (T1, E2, etc.) to provide me IPv4 Class C or better - I had to insist and spend time to get Class C.

That is IPv4. IPv6 is a very different ball game. No scarcity.

> I thought that an end user (like a vehicle manufacturer) would not be in a position to ask RIR directly.

You are mistaken.

> I guess it could cost a lot of money to ask for as many IPv6 subnets as VIN offers to that manufacturer.

In theory, a vehicle manufacturer could, within ARIN policy, approach ARIN with a desire to interconnect all of the vehicles they manufacture and treat each as a separate end-site with a /48. Getting that many /48s would, in fact, be rather expensive, but policy would allow them to do so.

> Do you mean that a person like in my position (I am not an ISP, nor a IXP) could ask RIR for e.g. a 61bit space? (i.e. asking a /3 prefix)? (sorry I bring vehicle in the picture, just to illustrate one particular need for ULAs that I think will grow - one single vehicle manufacturer by definition and without paying has the right to VIN space which roughly translates into 61bit space).

Obviously you aren't going to get a /3. I think the current policy in ARIN limits you to a maximum of a /12. However, I can absolutely guarantee you that no vehicle manufacturer has ever built enough vehicles to justify 61 bits of space. You are talking about more than 1,000,000,000,000,000,000 vehicles if you give each one
a /64. Even if you give each one a /48, you're still talking about more than 15,000,000,000,000 vehicles.

> Well, I would be careful with the first statement.  I am not sure there are enough IPv6 prefixes available to put one on each boson (if that boson had Interface ID of length 64).

I meant bogons, not bosons. It was a typo.

> The situation could be improved.  I think it would be easy to locate the ip6tables MASQUERADE C code and add a if condition by which if ULA then don't rewrite.  Then submit to kernel maintainers and suggest inclusion in mainline.

You miss the point completely. If you're going to MASQUERADE (NAT) IPv6, then it doesn't matter if you use ULA with your NAT or not. The problem is the use of NAT, not the use of ULA inside the NAT.

> It's the same as with link-local addressees - packets whose src/dst are such dont get forwarded, by a simple rule in the C code, in agreement with RFC.

No, it's very different with Link Local. Link Local carries lots of assumptions about not getting forwarded by routers. There's no such expectation with ULA.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 12:39:37 -0700

>  for the number of vehicles manufactured by one manufacturer in 10

No, RIR says /48 per end site is the MINIMUM.

It is also by default the maximum per end site because an end site is
defined as a single building or structure or a single tenant within a
building or structure and it is pretty much inconceivable that one of
those things would require more than 65,536 subnets.

In the manufacturer case, each vehicle would be an end site.

>  or for its other small fleet.

This is a RIPE oddity. This limitation does not exist outside of Europe
to the best of my knowledge. There is a process for changing this policy
in the RIPE region if you feel strongly about it.

>  would go), it may not work otherwise.

You are conflating disparate things here.

>  read and understand.  I will look later.

To which PDF do you refer?

> applications, or even vehicle-to-vehicle applications (without

Link Local is probably sufficient for most in-vehicle applications.

Owen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 29 Mar 2013 21:37:58 +0100

On 29 mrt 2013, at 20:21, Owen DeLong <[email-masked]> wrote:

> I am considering submitting the following as an internet draft. I wanted to get feedback from folks on this list about it first.

Since you ask...

First, either you are informational or you tell people what they SHOULD and SHOULDN'T do. Combining the two is problematic. Realize that you are in effect updating RFC 4193, which is standards track.

Second, disallowing the use of fd00:2001:db8::/48 the way RFC 4193 intends it to be used is problematic in my opinion, as now there can be people that use it as per RFC 4193 and people who use it as per draft-delong-... I think it would be better to suggest that fd00:2001:db8::/48 is used for documentation, but recognize that people using the procedure in RFC 4193 to generate a ULA prefix have a small chance of landing on fd00:2001:db8::/48 and therefore, this prefix shouldn't be treated differently from other ULA space.

Third, fd000::/8 ?

By the way, it's probably easier to submit the draft and ask people to find it in the draft repository than to attach it to an email and trust that email clients keep the formatting intact.

Iljitsch

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 13:45:41 -0700

> First, either you are informational or you tell people what they SHOULD and SHOULDN'T do. Combining the two is problematic. Realize that you are in effect updating RFC 4193, which is standards trac…

I thought I was updating 3849 which is Informational and the language in that regard is, btw, copied from 3849.

Do you have alternative language suggestions?

> Second, disallowing the use of fd00:2001:db8::/48 the way RFC 4193 intends it to be used is problematic in my opinion, as now there can be people that use it as per RFC 4193 and people who use it a…

I want more opinions, but I'm actually OK with going either way on this.

> Third, fd000::/8 ?

Typo.  Fixed.

> By the way, it's probably easier to submit the draft and ask people to find it in the draft repository than to attach it to an email and trust that email clients keep the formatting intact.

Fair enough. I wanted to at least run one pass by people here to get feedback (such as what you have provided) to have a decent chance of getting it published when submitted.

Owen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 29 Mar 2013 22:00:16 +0100

> I thought I was updating 3849 which is Informational and the language in that regard is, btw, copied from 3849.

That part is fine, but you are telling people to treat fd00:2001:db8::/48 differently from what RFC 4193 specifies.

> Do you have alternative language suggestions?

If you implement what I say below you are not going against RFC 4193 and there is no problem. Check your text for "should" and "must", though, these are dangerous words. Alternatively, make it an official update and use RFC 2119 language.

> I want more opinions, but I'm actually OK with going either way on this.

Ok.

> Fair enough. I wanted to at least run one pass by people here to get feedback (such as what you have provided) to have a decent chance of getting it published when submitted.

Many drafts are submitted, few are published.  :-)

A slight variation on Randy Bush: anyone with a keyboard and time on their hands can submit an internet draft.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Mar 2013 22:35:15 +0000

I think submitting as a draft would be the next logical step,
and I agree with Iljitsch's points which it sounds like Owen
is amenable to.

Thanks - Fred

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Iljitsch van Beijnum
> Sent: Friday, March 29, 2013 2:00 PM
> To: Owen DeLong
> Cc: [email-masked] WG
> Subject: Re: [v6ops] Documentation Prefixes for ULA
> 
> >> First, either you are informational or you tell people what they SHOULD
> and SHOULDN'T do. Combining the two is problematic. Realize that you are
> in effect updating RFC 4193, which is standards track.
> 
> That part is fine, but you are telling people to treat fd00:2001:db8::/48
> differently from what RFC 4193 specifies.
> 
> If you implement what I say below you are not going against RFC 4193 and
> there is no problem. Check your text for "should" and "must", though,
> these are dangerous words. Alternatively, make it an official update and
> use RFC 2119 language.
> 
> >> Second, disallowing the use of fd00:2001:db8::/48 the way RFC 4193
> intends it to be used is problematic in my opinion, as now there can be
> people that use it as per RFC 4193 and people who use it as per draft-
> delong-... I think it would be better to suggest that fd00:2001:db8::/48
> is used for documentation, but recognize that people using the procedure
> in RFC 4193 to generate a ULA prefix have a small chance of landing on
> fd00:2001:db8::/48 and therefore, this prefix shouldn't be treated
> differently from other ULA space.
> 
> >> By the way, it's probably easier to submit the draft and ask people to
> find it in the draft repository than to attach it to an email and trust
> that email clients keep the formatting intact.
> 
> > Fair enough. I wanted to at least run one pass by people here to get
> feedback (such as what you have provided) to have a decent chance of
> getting it published when submitted.
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 15:35:58 -0700

This is now an ID available at:

http://www.ietf.org/id/draft-delong-ula-example-00.txt

Unless there is objection, the next version will incorporate the changes suggested by Iljitsch.

Are there any other changes people would like to see?

Owen

---

From: David Farmer <[email-masked]>
Date: Fri, 29 Mar 2013 19:45:13 -0500

> Unless there is objection, the next version will incorporate the changes suggested by Iljitsch.

fd00:2001:db8::/48 should remain a valid ULA prefix as defined in RFC 
4193, but you might want to suggest it may be reasonable to establish 
local policy not to use it, even though it remains valid ULA prefix.

> Are there any other changes people would like to see?

As for fc00:2001:db8::/48, I would add something like the follow to what 
you said;

    If fc00::/8 were defined similar to contemplated in
    [draft-ietf-ipv6-ula-central] or [draft-hain-ipv6-ulac],
    fc00:2001:db8::/48 should be reserved in such a registry, if such a
    registry were ever created for fc00::/8.

Where draft-ietf-ipv6-ula-central and draft-hain-ipv6-ulac would be 
Informative References.

Since it has come up, is there any interest in moving forward some from 
of ULA-C?

Owen, has your views on the utility of registered ULA softened?

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 30 Mar 2013 01:21:36 +0000

I support the idea to assign a fixed prefixes for ULA documentation. fc00:2001:db8::/48 as documentation ULA prefix looks a good idea.

However, after read the current draft, I am very worried there are some problem in it. The blow are some concerns I have:

A, standard track vs informational. Ideally, the ULA Prefix Reserved for Documentation should be Informational, like RFC 3849 for IPv6 documentation prefix. However, being informational means it does not change any standard track meaning or existing implementations. My reading from the current ID is it requests change on both semantic and existing implementation. So, for my understanding, it has to be standard track if it remains the current form.

B, semantic change form RFC 4193. RFC4193 has defined L bit "Set to 0 may be defined in the future". But the current draft has override it by "registered (fc00::/8)". Personally, I think to create IANA registration for ULA prefix fc00::/8 may be an idea not bad at all. This need to formally update RFC4193. Consequently, this work should be done in 6man. 

C, fd00:2001:db8::/48 has magnificent important to the existing implementations. It requests all existing implementation to avoid this ranges in their random algorithm. I am not sure why you need two prefix for documentation usage. For me, fc00:2001:db8::/48 is enough to represent ULA. There is no need to distinguish whether its Global ID is randomly generated or not.

Best regards,

Sheng

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Owen DeLong
>Sent: Saturday, March 30, 2013 6:36 AM
>To: Iljitsch van Beijnum
>Cc: [email-masked] WG

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 30 Mar 2013 01:41:41 +0000

>Since it has come up, is there any interest in moving forward some from

Since you asked, I have no much issues for the ULA-C proposal.

However, I do not see much benefit or motivation from it, either. The only concrete benefit I can see is the guaranteed global uniqueness. The random algorithm in RFC4193 has only small collision chance, but no real guarantee for global uniqueness. On another side, ULA is only for local use and should not be announced to global routing system (global routing system can also easily filter the leaked ULA announcement). The global uniqueness of ULA seems not very critical.

If there are other benefit/motivation of ULA-C, I am glad to discuss further.

Best regards,

Sheng

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 22:51:53 -0700

On Mar 29, 2013, at 17:45 , David Farmer <[email-masked]> wrote:

> fd00:2001:db8::/48 should remain a valid ULA prefix as defined in RFC 4193, but you might want to suggest it may be reasonable to establish local policy not to use it, even though it remains valid ULA prefix.
> 
> As for fc00:2001:db8::/48, I would add something like the follow to what you said;
> 

Actually, I would rather leave it as is. If the travesty of ULA-C ever comes to be, then
I would not want to limit the authors options with this older document. Instead, I would
expect them to consider this reservation and make a decision whether a documentation
prefix within that space is desirable. If so, then it has already been set aside for their
convenience. If not, then this becomes yet another piece of road kill on the information
super highway.

> Where draft-ietf-ipv6-ula-central and draft-hain-ipv6-ulac would be Informative References.

I'd rather not make informative references to expired drafts if I can avoid it.

> Since it has come up, is there any interest in moving forward some from of ULA-C?

Not from me there isn't.

> Owen, has your views on the utility of registered ULA softened?

Not in the least. Personally, I'd rather eliminate ULA altogether, but given the current bad
situation, not having a documentation prefix is likely to make it worse. As such, this seeks
to use the art of the possible to minimize the damage.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 22:54:29 -0700

> A, standard track vs informational. Ideally, the ULA Prefix Reserved for Documentation should be Informational, like RFC 3849 for IPv6 documentation prefix. However, being informational means it do…

This will be corrected in -01.

> B, semantic change form RFC 4193. RFC4193 has defined L bit "Set to 0 may be defined in the future". But the current draft has override it by "registered (fc00::/8)". Personally, I think to create…

I will also attempt to correct this in -01. If you have language suggestions, they are appreciated.

> C, fd00:2001:db8::/48 has magnificent important to the existing implementations. It requests all existing implementation to avoid this ranges in their random algorithm. I am not sure why you need t…

Unless you are seeking to make examples of these two different usages of ULA, which is a very likely scenario should L=0 ever become defined.

I don't believe fd00:2001:db8::/48 has magnificent importance to existing implementations and with the corrections to A, even that will not really be a problem.

Owen

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 30 Mar 2013 08:04:40 +0000

>> B, semantic change form RFC 4193. RFC4193 has defined L bit "Set to 0 may
>be defined in the future". But the current draft has override it by "registered
>(fc00::/8)". Personally, I think to create IANA registration for ULA prefix
>fc00::/8 may be an idea not bad at all. This need to formally update RFC4193.
>Consequently, this work should be done in 6man.
>

It depends on whether you want to create a IANA registration for whole fc00::/8 or not. If yes, most of ULA-C can be imported. If no, you can just say something like: this document proposes to reserve a /48 prefix for ULA documentation usage from the address space that RFC4193 reserved for future usage. IANA should create a registration entry for this reserved /48 prefix.

>> C, fd00:2001:db8::/48 has magnificent important to the existing
>implementations. It requests all existing implementation to avoid this ranges
>in their random algorithm. I am not sure why you need two prefix for
>documentation usage. For me, fc00:2001:db8::/48 is enough to represent
>ULA. There is no need to distinguish whether its Global ID is randomly
>generated or not.
>
>Unless you are seeking to make examples of these two different usages of
>ULA, which is a very likely scenario should L=0 ever become defined.

Unless we are already clear what two different usages are, we don't have to distinguish them. For now, we only have one concrete ULA usage, which covers by L=1.

>I don't believe fd00:2001:db8::/48 has magnificent importance to existing
>implementations and with the corrections to A, even that will not really be a
>problem.

Sorry for typo. I was mean "magnificent impact". All existing implementation need to be modified to avoid this ranges if their random algorithms happen to collide. The modification may not be big. Personally, I believe IETF should avoid to change existing implementation as much as possible.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Mar 2013 08:23:23 +0000

On 30/03/2013 00:45, David Farmer wrote:
...
> Since it has come up, is there any interest in moving forward some from

I don't see why. Although it could be automated, there is a cost involved
in any form of guaranteed uniqueness, and that cost simply isn't justified
by the tiny probability of a ULA prefix collision.

The considerably greater cost of a PI prefix applies if a site wants
routeability, but that's beside the point.

As for Owen's draft, I have a counter-proposal. Just use the "zero"
addresses as the documentation prefixes:

   The proposed prefixes are fd00::/48 (example Locally Assigned
   Global ID) and fc00::/48 (example possible future use), respectively.

These will work perfectly well as examples, and are simple and
straightforward to include in operational filters and exclude
in ULA-generation algorithms. Also, using them as the documentation
prefixes will make it even more egregious to use them as lazy choices.

   Brian

PS I think the draft belongs in 6man.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Mar 2013 08:47:12 +0000

On 29/03/2013 17:58, Owen DeLong wrote:
...
> Even if you choose to use ULA for stable internal addressing, there is still no valid reason not to use PA or PI space for your external connectivity. 

With an emphasis on the "or".

A billion SOHOs each with their own PI prefix announced in BGP4+ is not
a realistic option. If 99.99% of SOHOs use a PA prefix, we will be fine.

Those are not unrealistic numbers.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Mar 2013 09:48:14 +0100

> addresses as the documentation prefixes:

Hm, the downside of that is that due to the zero compression those prefixes look very different from "normal" ones and thus don't make for good examples.

Of course anyone can generate any number of ULAs to do with as they please, including using them in examples.

Iljitsch

---

From: Randy Bush <[email-masked]>
Date: Sat, 30 Mar 2013 17:51:09 +0900

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 30 Mar 2013 20:17:10 +0100

Joël,

Thanks for the message.  Reply below.

> https://www.arin.net/policy/nrpm.html#six58

Ok, that seems to say
"Provider independent (portable) addresses issued directly from ARIN or 
other Regional Registries are not guaranteed to be globally routable."

I suppose it would be hardly acceptable to put PI space in a vehicle and 
suppose that Internet-at-wide not to be reachable.

If by that statement ARIN means that a communication flow issued out of 
a vehicle may need to first get through some 'upstream provider' or 
'provider's provider', then this may pose challenges to straight 
vehicle-to-vehicle communications as well.

> datacenters received a /44 under the  ARIN policy...

Ok, this is good to know.

> meeting in berlin, (they're not that far away) and talk about their

Yes,  I would like to ask them to come to IETF Berlin and present their 
assignment experience: is that /29 for offices or for vehicles, or both, 
prefixlen inside a vehicle, etc.

This invitation may not be that simple to do, and I need help for that.
(in which WG to present, should they write first a draft, etc.)  These 
are problems I face daily with other parties which may be interested, if.

[...]

[...]

Alex

---

From: joel jaeggli <[email-masked]>
Date: Sat, 30 Mar 2013 13:24:49 -0700

On 3/30/13 12:17 PM, Alexandru Petrescu wrote:
> "Provider independent (portable) addresses issued directly from ARIN 
> or other Regional Registries are not guaranteed to be globally routable."
>
It says that for ipv4 as well... address assignment by an rir is not a 
license to route, nor is it an assurance that network operators will 
accept your prefix.
> I suppose it would be hardly acceptable to put PI space in a vehicle 
> and suppose that Internet-at-wide not to be reachable.
If you advertise a route longer than a /48  today the chances of it 
being accepted globally on the internet today are about zero.

> If by that statement ARIN means that a communication flow issued out 
> of a vehicle may need to first get through some 'upstream 
> provider' or 'provider's provider', then this may pose challenges to 
> straight vehicle-to-vehicle communications as well.

RIRs are not involved in the topology consideration, they assign 
addresses, and provide attestations about the validity of things.

Locally signficant routing and adjacency decisions are clearly relevant 
locally. You have (imho) a set of separable problems, machine to machine 
communication vs internet connectivity) and they can be solved in all 
likelihood without boiling an ocean. Today, cars with internet 
connectivity receive addressing from a service provider, sometimes more 
than one, I don't see any reason to expect that model is unworkable in 
the future, wether they do that becasue of a relationship between the 
manufacturer and the service provider (as is frequently the case) the 
consumer and the service provider, or some device to which they are 
tethered doesn't seem particularly relevant. Using more than one address 
range, e.g. a provider assigned one, and a locally significant one 
doesn't seem particularly daunting either.

> Yes,  I would like to ask them to come to IETF Berlin and present 
> their assignment experience: is that /29 for offices or for vehicles, 
> or both, prefixlen inside a vehicle, etc.
>
volkswagen ag is clearly an LIR in the scope of it's ripe prefix 
assignment...

I have no particular insight into how they use that prefix. A rather 
small portion of it appears into the ipv6 routing table.

It has generally been my experience that enterprises that need address 
space are able to work within the system as it exists now to secure the 
resources that they need. Clearly that is getting harder with IPv4.  I 
don't see much evidence for that's a problem in IPv6.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 31 Mar 2013 01:01:41 -0700

> "Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable."
> 

Correct.

> I suppose it would be hardly acceptable to put PI space in a vehicle and suppose that Internet-at-wide not to be reachable.
> 

Why?

> If by that statement ARIN means that a communication flow issued out of a vehicle may need to first get through some 'upstream provider' or 'provider's provider', then this may pose challenges to straight vehicle-to-vehicle communications as well.
> 

That statement simply means "ARIN doesn't control the routers and has no authority over those who do."

When you attempt to advertise a prefix, it is up to your peers, upstreams, etc. and up to each individual more distant network whether or not they accept it into their routing table.

I wouldn't read much more into it.

Owen

---

From: Ray Hunter <[email-masked]>
Date: Sun, 31 Mar 2013 10:06:38 +0200

Alexandru Petrescu wrote:
> Le 29/03/2013
>>> <snip>

Correct. RIRs are address registration authorities.

How an LIR routes their assigned prefixes to the global Internet (or
not) is the LIR's problem.
> and suppose that Internet-at-wide not to be reachable.

Why would that happen?
> of a vehicle may need to first get through some 'upstream provider' or

No. Not at all.

There is no link between an RIR's allocation policy and an LIR"s peering
policy.
An LIR is free to peer with whomever they like.

I think the automotive guys can even do that with their existing PA
space, never mind PI, because they *are already* the LIR in most cases.

There are any number of existing protocols that will allow an automotive
LIR to create a contiguous network over various media (including the
public Internet operated by other LIRs), and then break out to the
Public Internet at a number of gateways with a (large) summary route
that would be globally routed. e.g. take a /32 and split it into 16
/36's with a breakout per sub region e.g. NA-E, NA-W, SA, EU, Africa,
AP-N, AP-S, India, China .....

How do think today's enterprise networks work (for travelling users with
laptops)?

Suggest you check out: NHRP, SSL, GRE, IPSec tunnel mode .....

I humbly suggest that you do not think of a car as a single end host,
but rather a small site that moves around, that you then decompose your
problem into many different communication flows, and then I'm pretty
convinced you'll find an existing off-the-shelf solution for the vast
majority of your problems. I think it would also help if you went and
talked to some large corporate network operators.

I'd be happy to help (offline).

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 31 Mar 2013 19:43:09 +0200

> not) is the LIR's problem.

Ok...

>> and suppose that Internet-at-wide not to be reachable.

If there is doubt about the PI space being or not routed to the Internet 
by the organization who provided that PI space then it is useless as 
"PI".  ULA would make more sense - we know for sure it shouldnt be 
routed to Internet.

Or I misunderstand PI entirely.

> An LIR is free to peer with whomever they like.

Ok, but what about a vehicle?

Suppose a vehicle has a PI or PA /63 inside it (not ULA), and another 
vehicle has another different such /63.

Each of that /63 is valid at one or several points in the Internet, ok 
(i.e. someone else's router points to it).

Would those two vehicles be ok to exchange their respective /63s?  I 
don't think so, because it may create loops.  Their prefixes should be 
advertised _only_ at the place which is correct.

One couldn't imagine that one particular stable prefix of a vehicle 
could be advertised to all random vehicle passing by, which itself may 
be connected to Internet, etc.

> How do think today's enterprise networks work (for travelling users with

VPN - ok.

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.

> I'd be happy to help (offline).

YEs, let us exchange offline about this.

Additionally, for information, there is this ITS email list at ietf:
ietf.org/mailman/listinfo/its

In v6ops WG I find there is a right mindset and skill for IPv6 
operational addressing architecture which may pertain to vehicular 
communications.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 31 Mar 2013 19:54:18 +0200

Le 30/03/2013 21:24, joel jaeggli a écrit :
[...]

> Locally signficant routing and adjacency decisions are clearly
> relevant locally.

YEs right.  And there is a difference between adjacency of two large
fixed sites (Enterprise) and more dynamic adjacency as in moving vehicles.

> You have (imho) a set of separable problems, machine to machine
> communication vs internet connectivity)

YEs, that is right.  V2V communications problems could be separated from
the Internet connectivity problems (although there's als argument about
'nested' mobility which realizes both at the same time).

> and they can be solved in all likelihood without boiling an ocean.

Ok, vehicular communications are one particular aspect in v6ops.  That
aspect may be the necessity of ULA.  All I am trying to say - dont kill
ULA.  And each time I have to explain why, only for this particular reason.

Ido not boil the ocean.  There is another list where this could be 
discussed: its, ietf.org/mailman/listinfo/its.

> Today, cars with internet connectivity receive addressing from a
> service provider, sometimes more than one,

Curious about that 'sometimes' - I never saw.

> I don't see any reason to expect that model is unworkable in the
> future,

If an operator puts a prefix into a vehicle, would that vehicle be 
allowed to advertise that same prefix to another vehicle (i.e. inform 
that other vehicle it owns that prefix, so route to it) - and vice 
versa.  Or would that create routing problems?

These are dynamic relationships which last maybe a few minutes or so.

> wether they do that becasue of a relationship between the
> tethered doesn't seem particularly relevant. Using more than one
> address range, e.g. a provider assigned one, and a locally
> significant one doesn't seem particularly daunting either.

I agree in that sense, yes, two different address spaces for different 
purposes.

Are you saying that one such PI space should be used instead of ULA?

I.e. put PI inside a vehicle, and would be ok to do routing with this PI 
directly between vehicles?

I.e. use a PI as if we were it's never routed to the Internet?

I am lost.

>>> My company with 11 current locations 5 of which were at time of
>>> request datacenters received a /44 under the  ARIN policy...
>>
>>> let's look elsewhere... (maybe you should ask these folks to
>>> come to the meeting in berlin, (they're not that far away) and
>>> talk about their assignment experience).
>>
>> their assignment experience: is that /29 for offices or for
>> vehicles, or both, prefixlen inside a vehicle, etc.
>>
> It has generally been my experience that enterprises that need
> address space are able to work within the system as it exists now to
> secure the resources that they need. Clearly that is getting harder
> with IPv4.  I don't see much evidence for that's a problem in IPv6.

I tend to agree yes.

Alex

>> This invitation may not be that simple to do, and I need help for
>> that. (in which WG to present, should they write first a draft,
>> etc.) These are problems I face daily with other parties which may
>> be interested, if.
>>
>>> joels-MacBook-Air:~ jjaeggli$ whois -h whois.ripe.net
>>> 2a01:4dc0::/29 % This is the RIPE Database query service.
>> [...]
>>> inet6num:       2a01:4dc0::/29 netname: DE-VOLKSWAGENAG-20120530
>>> descr:          Volkswagen AG country: DE org:
>>> ORG-VA303-RIPE admin-c:        VWAG1-RIPE tech-c:
>>> VWAG1-RIPE status:         ALLOCATED-BY-RIR mnt-by:
>>> RIPE-NCC-HM-MNT mnt-lower:      AB82394-MNT mnt-routes:
>>> AB82394-MNT source:         RIPE # Filtered
>>
>> [...]
>>
>> Alex
>>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 31 Mar 2013 19:57:24 +0200

Le 31/03/2013 10:01, Owen DeLong a écrit :
>> Ok, that seems to say "Provider independent (portable) addresses
>> issued directly from ARIN or other Regional Registries are not
>> guaranteed to be globally routable."
>>
>
> Correct.
>
>> I suppose it would be hardly acceptable to put PI space in a
>> vehicle and suppose that Internet-at-wide not to be reachable.
>>
>
> Why?
>
>> If by that statement ARIN means that a communication flow issued
>> out of a vehicle may need to first get through some 'upstream
>> provider' or 'provider's provider', then this may pose challenges
>> to straight vehicle-to-vehicle communications as well.
>>
>
> When you attempt to advertise a prefix, it is up to your peers,
> upstreams, etc. and up to each individual more distant network
> whether or not they accept it into their routing table.

These peers and upstreams seem to me as entities which develop longer 
term relationships between them (like when sysadmins know each other, 
orgs sign contracts, SLAs, and so on).

This would be hardly feasible between two other vehicles following each 
other the time of a traffic jam.

Who would be the upstream of the other for 10 minutes... etc.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Sun, 31 Mar 2013 13:06:32 -0700

On Mar 31, 2013, at 10:57 , Alexandru Petrescu <[email-masked]> wrote:

> These peers and upstreams seem to me as entities which develop longer term relationships between them (like when sysadmins know each other, orgs sign contracts, SLAs, and so on).
> 
> This would be hardly feasible between two other vehicles following each other the time of a traffic jam.
> 

Right... We were talking about internet routing and the statement from the RIR about prefixes not being guaranteed by the RIR to be routable on the internet.

Obviously two vehicles following each other in a traffic jam are unlikely to be involved in global routing of a prefix in any meaningful way.

> Who would be the upstream of the other for 10 minutes... etc.

Your questions make no sense to me in the context. One of us is very much NOT understanding the other. I am not sure which.

For vehicles, the most likely upstreams would be cellular networks, wifi, or other such services. Probably on a somewhat dynamic basis using locally assigned PA addresses for the links and MIP to actually carry the permanent addresses.

I suppose something like a 6lowpan mesh of automobiles could eventually deliver some services for very low bandwidth applications.

However, you really need to try and find a way to wrap your head around the fact that routing and end point identity are two very distinct and separate applications for IP addresses. In a fixed scenario, it sometimes makes sense to use the same address for both purposes and topology will dictate the prefix.

In the mobile scenario, you need to, instead, consider that there will be different IP addresses used for these purposes and some form of Map/Encap will likely be used, whether that includes LISP, MIP, other various technologies such as IRON, etc. is yet to be determined and no one answer may fit every scenario.

Further, the selection of solution and the choice of infrastructure, routing, protocols, etc. can be fluid and dynamic as well.

You have often talked about various options which can work in parallel as if they are mutually exclusive.

Owen

---

From: Randy Bush <[email-masked]>
Date: Mon, 01 Apr 2013 08:55:22 +0900

> If there is doubt about the PI space being or not routed to the
> Internet by the organization who provided that PI space then it is
> useless as "PI".  ULA would make more sense - we know for sure it
> shouldnt be routed to Internet.

either may be announced or not at the holder's discretion.  who is
willing to listen may vary.

randy