Subject: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt

From: Mark Smith <[email-masked]>
Date: Mon, 11 Feb 2013 12:20:05 -0800 (PST)

Hi,

Here is a new version of my IPv6 larger loopback prefix draft. Changes since the previous version:

o  default address selection precedence and label values
o  comment about other IPv4 in IPv6 address forms

o  more clarifications

o  grammar corrections

My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou for their review and comments on this revision.

Further review and comments would be most appreciated.

Thanks,
Mark. 

----- Forwarded Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Tuesday, 12 February 2013 7:12 AM
> Subject: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt
> 
> 
> A new version of I-D, draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt
> has been successfully submitted by Mark Smith and posted to the
> IETF repository.
> 
> Filename:     draft-smith-v6ops-larger-ipv6-loopback-prefix
> Revision:     03
> Title:         A Larger Loopback Prefix for IPv6
> Creation date:     2013-02-11
> WG ID:         Individual Submission
> Number of pages: 12
> URL:            
> http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt
> Status:          
> http://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix
> Htmlized:        
> http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-03
> Diff:            
> http://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-larger-ipv6-loopback-prefix-03
> 
> Abstract:
>    During the development and testing of a network application, it can
>    be useful to run multiple instances of the application using the same
>    transport layer protocol port on the same development host, while
>    also having network access to the application instances limited to
>    the local host.  Under IPv4, this has been possible by using
>    different loopback addresses within 127/8.  It is not possible under
>    IPv6, as the loopback prefix of ::1/128 only provides a single
>    loopback address.  This memo proposes a new larger loopback prefix
>    that will provide many IPv6 loopback addresses.
> 
>                                                                                 
>   
> 
> 
> The IETF Secretariat
>

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Feb 2013 12:28:19 -0800

Perhaps I'm not very bright, but is there any reason ULA couldn't be used on the LO interface to
satisfy this corner case?

Owen

On Feb 11, 2013, at 12:20 , Mark Smith <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Smith <[email-masked]>
Date: Mon, 11 Feb 2013 12:48:03 -0800 (PST)

>From the Intro:

"A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be used to increase the number of addresses available on the local host. However this prefix would need to be manually generated and configured at least once by a system administrator or operator. Without additonal configuration, traffic towards addresses not assigned to the local host would not be prevented from leaving the host, and access may not be limited to the local host.  A ULA prefix would not be well known, and would not be convenient to remember and type without violating the randomness requirements of the Global ID component of a ULA prefix."

For reference, the "candidate" existing unicast addresses that are either covered in the draft or people have raised with my off-list (and I don't think are necessary to cover in the draft) are
- ULA
- link local prefix on loopback
- 100.64/10
- 100::/64
In all cases, they would not be user friendly enough (I used a ULA for this purpose during development of http://developer.berlios.de/projects/replicast/), would need operator intervention to enable rather than always being available, or would be overloading the existing purpose of the prefix and therefore the prefix's use would have to be respecified.
The fundamental problem is that ::1/128 contains only one address, the fundamental solution is to preserve the loopback prefix functionality, utility and ubiquity but make it bigger. 

----- Original Message -----
> From: Owen DeLong <[email-masked]>
> To: Mark Smith <[email-masked]>
> Cc: v6ops v6ops WG <[email-masked]>
> Sent: Tuesday, 12 February 2013 7:28 AM
> Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt
> 
>>>  Subject: New Version Notification for 
> draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt
>>> 
>>> 
>>>  A new version of I-D, 
> draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt

---

From: Ole Troan <[email-masked]>
Date: Mon, 11 Feb 2013 22:32:50 +0100

> - link local prefix on loopback

::/96 ?

cheers,
Ole

---

From: David Farmer <[email-masked]>
Date: Mon, 11 Feb 2013 15:37:10 -0600

> satisfy this corner case?

The Draft does cover why ULA is thought to not be a sufficient solution, 
do you disagree with the reasoning in the draft?

from Section 1;

    A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be
    used to increase the number of addresses available on the local host.
    However this prefix would need to be manually generated and
    configured at least once by a system administrator or operator.
    Without additonal configuration, traffic towards addresses not
    assigned to the local host would not be prevented from leaving the
    host, and access may not be limited to the local host.  A ULA prefix
    would not be well known, and would not be convenient to remember and
    type without violating the randomness requirements of the Global ID
    component of a ULA prefix.

-- 
================================================
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: Doug Barton <[email-masked]>
Date: Mon, 11 Feb 2013 14:46:22 -0800

The draft does cover that, yes. The question is not, "Is ULA harder?" 
the question is, "Is the extra work required by the draft for EVERY 
IMPLEMENTATION worth it to handle the corner case described in the draft?"

Note, I don't know the answer, but I'm leaning heavily towards, "no."

Primarily because we're asking people to deploy this protocol for 
real-world scenarios, and we already have a pretty wide divergence in 
the latest state of the standards vs. the oldest working deployed base. 
Widening that gap should only be done for truly critical changes, and 
I'm not sure you've made your case sufficiently.

Put more simply, at some point we have to stop tinkering with the plane 
while it's in the air.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Feb 2013 16:11:06 -0800

My reading of the draft leads me to believe that there is no gain in creating an expanded loopback prefix instead of
a simple recommendation that people faced with the challenge of wanting more addresses on a loopback interface
simply configure ULA addresses onto that interface.

Admittedly, I haven't tested this exhaustively, but on Linux and MacOS, I get good results:

[root@owen ~]# ifconfig lo
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:45357270 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45357270 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:460117602 (438.8 MiB)  TX bytes:460117602 (438.8 MiB)

[root@owen ~]# ifconfig lo add fd00:0db8::1/64
[root@owen ~]# ifconfig lo
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: fd00:0db8::1/64 Scope:Global
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:45357276 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45357276 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:460118944 (438.8 MiB)  TX bytes:460118944 (438.8 MiB)

As such, I would rather document that a loopback interface "should" support additional addresses like any other
interface and let people use ULA, GUA, etc. for that purpose than create yet another special-case prefix with the
attendant requirement that everyone modify their code.

It seems to me that the existence of a valid solution which does not require tinkering with the plane at all (at least
in many cases) is preferable to one that requires tinkering with all of the airplanes in flight (which is my understanding
of the current draft).

If I have misread something, I apologize.

Owen

---

From: Mark Smith <[email-masked]>
Date: Mon, 11 Feb 2013 23:06:01 -0800 (PST)

----- Original Message -----
> From: Doug Barton <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Tuesday, 12 February 2013 9:46 AM
>T he draft does cover that, yes. The question is not, "Is ULA harder?" 

127.0.0.1/8 has proven to be useful, despite it being a solution to "a corner case". There was an opportunity to drop it being a ubiquitous feature of IPv6 when IPv6 was being designed, yet the idea was retained, and now all IPv6 implementations have a special purpose ::1/128 address created by default.

I think anything that can make development of IPv6 applications easier and more convenient should be considered. Time application developers spend on setting up their development environments is time taken away from developing the applications themselves. While developing the application I did, I found using a ULA prefix to gain more host local addresses cumbersome, and would have much rather had an autoconfigured, and easy to remember and type loopback IPv6 prefix that had more than one address.

This proposal also takes the opportunity to introduce IPv4-like handling of loopback IPv6 packets so that future functions similar to the use in RFC4379 have a native IPv6 address space to use, rather than using 127/8 within an IPv6 prefix.

> Put more simply, at some point we have to stop tinkering with the plane 

So I think the implication of that analogy is that deploying this enhancement will somehow interrupt the existing operation of IPv6 implementations ("the plane") causing them to fail ("fall out of the sky"). I don't see how that will be the case. Deploying a new loopback prefix would leverage many of the existing address configuration and loopback related functions of existing IPv6 implementations. It is not much more than a larger version of ::1/128.

Regards,
Mark.

>>>  Perhaps I'm not very bright, but is there any reason ULA 
> couldn't be
>>>  used on the LO interface to

---

From: Mark Smith <[email-masked]>
Date: Mon, 11 Feb 2013 23:14:48 -0800 (PST)

Hi Ole,

----- Original Message -----
> From: Ole Troan <[email-masked]>
> Cc: Owen DeLong <[email-masked]>; v6ops v6ops WG <[email-masked]>
> Sent: Tuesday, 12 February 2013 8:32 AM
> Subject: Re: [v6ops] New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-03.txt
> 
>>  "A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be 
> used to increase the number of addresses available on the local host. However 
> this prefix would need to be manually generated and configured at least once by 
> a system administrator or operator. Without additonal configuration, traffic 
> towards addresses not assigned to the local host would not be prevented from 
> leaving the host, and access may not be limited to the local host.  A ULA prefix 
> would not be well known, and would not be convenient to remember and type 
> without violating the randomness requirements of the Global ID component of a 
> ULA prefix."
>> 
>>  For reference, the "candidate" existing unicast addresses that 
> are either covered in the draft or people have raised with my off-list (and I 
> don't think are necessary to cover in the draft) are
>>  - ULA
>>  In all cases, they would not be user friendly enough (I used a ULA for this 
> purpose during development of http://developer.berlios.de/projects/replicast/), 
> would need operator intervention to enable rather than always being available, 
> or would be overloading the existing purpose of the prefix and therefore the 
> prefix's use would have to be respecified.
>>  The fundamental problem is that ::1/128 contains only one address, the 
> fundamental solution is to preserve the loopback prefix functionality, utility 
> and ubiquity but make it bigger. 
> 
> ::/96 ?
> 

I figure that it'd be better to make a new larger loopback prefix resemble common, native IPv6 addressing, so I think it'd be better to have a prefix length of at least /64 to support 64 bit IIDs. Then, to generally make it most useful, provide many /64s instead of just one. The original proposal was a /48, however since within 0000::/8, there are 16 million /32s, so a /32 would be cheap for this purpose. Exceeding the number of /64s in a /48 is unlikely but perhaps conceivable (perhaps something related to virtualisation?), where as exceeding the /64s in a /32 would seem to me to be both unlikely and inconceivable (but hey, there are 256 /16s inside 0000::/8, so 1::/16 as a larger loopback prefix is feasible if somebody can think of a reason it might be useful!)  

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Feb 2013 10:46:58 -0800

On Feb 11, 2013, at 11:06 PM, Mark Smith <[email-masked]> wrote:

> I think anything that can make development of IPv6 applications easier and more convenient should be considered. Time application developers spend on setting up their development environments is time taken away from developing the applications themselves. While developing the application I did, I found using a ULA prefix to gain more host local addresses cumbersome, and would have much rather had an auto configured, and easy to remember and type loopback IPv6 prefix that had more than one address.

?? I don't see how it gets easier to remember than fd00::/8 and you can use anything you want inside of that to provide a /64 for your development purpose.

What's more cumbersome about picking something (even fd00::/64, if you want) for development than having some other prefix you have to configure assigned by the IETF.

Sorry, but I just don't get it.

> This proposal also takes the opportunity to introduce IPv4-like handling of loopback IPv6 packets so that future functions similar to the use in RFC4379 have a native IPv6 address space to use, rat…

In my (admittedly limited) testing, putting a /64 of ULA on the loopback interface did just that, so I'm not sure what it is that you feel is missing.

> So I think the implication of that analogy is that deploying this enhancement will somehow interrupt the existing operation of IPv6 implementations ("the plane") causing them to fail ("fall out of…

The implication is that you are requesting to once again obsolete all existing implementations in favor of requiring deploying another fundamentally changed IPv6 stack. The question is whether there is enough value in the change to justify such a decision and IMHO, at this point, just to make it "less cumbersome" than putting (a) ULA address(es) on the loopback interface strikes me as not having much value.

Owen

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Feb 2013 11:43:35 -0800 (PST)

----- Original Message -----
> Cc: Doug Barton <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, 13 February 2013 5:46 AM
>>>  Subject: Re: [v6ops] Fw: New Version Notification for 
>>  127.0.0.1/8 has proven to be useful, despite it being a solution to "a 
> corner case". There was an opportunity to drop it being a ubiquitous 
> feature of IPv6 when IPv6 was being designed, yet the idea was retained, and now 
> all IPv6 implementations have a special purpose ::1/128 address created by 
> default.
>> 
>>  I think anything that can make development of IPv6 applications easier and 
> more convenient should be considered. Time application developers spend on 
> setting up their development environments is time taken away from developing the 
> applications themselves. While developing the application I did, I found using a 
> ULA prefix to gain more host local addresses cumbersome, and would have much 
> rather had an auto configured, and easy to remember and type loopback IPv6 
> prefix that had more than one address.
> 
> ?? I don't see how it gets easier to remember than fd00::/8

The random bit is the hard bit to remember and type. I don't think you're thinking enough about how it is to use, you're only thinking about how hard it is to configure. The time and effort to configure something is usually minimal compared to the amount of time and effort spent while it is being used.

> and you can use 

> anything you want inside of that to provide a /64 for your development purpose.
> 
> What's more cumbersome about picking something (even fd00::/64, if you want) 

No, that's bad, as it is a ULA prefix which doesn't have a random component. Add the random component (if you aren't lazy), and it then becomes hard to remember and type.

> for development than having some other prefix you have to configure assigned by 

> the IETF.

I'm starting to wonder if you've actually read the draft. The intention is that it is that the larger loopback prefix automatically configured at system initialisation, as ::1/128 and 127/8 currently are. There is a whole section on automatic address assignment and configuration.

>>  This proposal also takes the opportunity to introduce IPv4-like handling of 
> loopback IPv6 packets so that future functions similar to the use in RFC4379 
> have a native IPv6 address space to use, rather than using 127/8 within an IPv6 
> prefix.
> 
> In my (admittedly limited) testing, putting a /64 of ULA on the loopback 
> interface did just that, so I'm not sure what it is that you feel is 
> missing.
> 

All addresses within 127/8 are valid and available on the host, where as with your ULA, only 1 is.

e.g.

[root@opy mark]# ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 fd00:db8::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 1::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

[root@opy mark]# ping -c 1 127.1.2.3
PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data.
64 bytes from 127.1.2.3: icmp_req=1 ttl=64 time=0.053 ms

--- 127.1.2.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms
[root@opy mark]# 

[root@opy mark]# ping6 -c 1 fd00:db8::2

connect: Network is unreachable
[root@opy mark]#

[mark@opy ~]$ ssh 127.1.2.3
The authenticity of host '127.1.2.3 (127.1.2.3)' can't be established.

[mark@opy ~]$ ssh -6 fd00:db8::2
ssh: connect to host fd00:db8::2 port 22: Network is unreachable
[mark@opy ~]$

Another test you should do to measure the usefulness of this proposal is see how long it takes and your opinion afterwards of how hard or easy it is to type or cut and paste "fd00:db8::1" vs "1::1" a reasonable number of times e.g. 6 times.

Using a ULA doesn't really work at all. It only adds another address to the host, rather than many. A properly formed ULA is hard to type and remember. It's far less user friendly than the short larger loopback prefix I'm proposing. This is based on my experience, as I've used a ULA for the purpose of trying to increase the number of loopback IPv6 addresses.

>>>  Note, I don't know the answer, but I'm leaning heavily towards, 
> 
>>>  "no."
>>> 
>>  So I think the implication of that analogy is that deploying this 
> enhancement will somehow interrupt the existing operation of IPv6 
> implementations ("the plane") causing them to fail ("fall out of 
> the sky"). I don't see how that will be the case. Deploying a new 
> loopback prefix would leverage many of the existing address configuration and 
> loopback related functions of existing IPv6 implementations. It is not much more 
> than a larger version of ::1/128.
> 
> The implication is that you are requesting to once again obsolete all existing 
> implementations in favor of requiring deploying another fundamentally changed 
> IPv6 stack.

Can you define the threshold of "fundamentally changed" for me?

I don't consider this to be a fundamental change. It is adding another loopback prefix, which operates the same as the existing one, just with a shorter prefix length. It is adding values to the source and destination address selection policy, which is already possible to do because it's been designed that way. I'm quite confident that it is going to be no more than 10 lines, and probably closer to 5 additional lines of code in a stack for a host implementation that only supports a single loopback interface. That's code change size closer to the size of bug fixes than additional functionality.

My definition of a fundamental change would be to do something like change the change the size of the IPv6 address, or reorder the fields in the IPv6 header.

> The question is whether there is enough value in the change to 
> justify such a decision and IMHO, at this point, just to make it "less 
> cumbersome" than putting (a) ULA address(es) on the loopback interface 
> strikes me as not having much value.
> 
> Owen
> 
>>   
>> 
>>  Regards,
>>  Mark.
>> 
>> 
>>>  Doug
>>> 
>>> 
>>>>>>  Here is a new version of my IPv6 larger loopback prefix 
> draft.
>>>>>>  Changes since the previous version:
>>>>>> 
>>>>>>  My thanks to Bill Atwood, Matts Kallioniemi and Tina Tsou 
> for their
>>>>>>  review and comments on this revision.
>>>>>>

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Feb 2013 11:59:10 -0800

> The random bit is the hard bit to remember and type. I don't think you're thinking enough about how it is to use, you're only thinking about how hard it is to configure. The time and effort to conf…

Nothing requires you to use random for this purpose. Use fd00::/64 for all anyone cares.

> No, that's bad, as it is a ULA prefix which doesn't have a random component. Add the random component (if you aren't lazy), and it then becomes hard to remember and type.

Why is it bad that it doesn't have a random component? If it's in a development test lab, it's not like it's at risk of corporate merger conflicts, etc.

> I'm starting to wonder if you've actually read the draft. The intention is that it is that the larger loopback prefix automatically configured at system initialisation, as ::1/128 and 127/8 current…

127/8 isn't auto-assigned. 127.0.0.1/8 is.

> rtt min/avg/max/mdev = 0.053/0.053/0.053/0.000 ms

Interesting… I get this behavior on MacOS.

[tc01-dhcp153:~] owen% ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128 

[tc01-dhcp153:~] owen% ping 127.1.2.3
PING 127.1.2.3 (127.1.2.3): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- 127.1.2.3 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

Admittedly, Linux does this:

owen.delong.com:owen /home4/owen (22) % ifconfig lo
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:45816328 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45816328 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:578712867 (551.9 MiB)  TX bytes:578712867 (551.9 MiB)

owen.delong.com:owen /home4/owen (23) % ping 127.1.2.3
PING 127.1.2.3 (127.1.2.3) 56(84) bytes of data.
64 bytes from 127.1.2.3: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 127.1.2.3: icmp_seq=2 ttl=64 time=0.032 ms
64 bytes from 127.1.2.3: icmp_seq=3 ttl=64 time=0.019 ms
^C
--- 127.1.2.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.019/0.031/0.043/0.010 ms
owen.delong.com:owen /home4/owen (24) % 

> ssh: connect to host fd00:db8::2 port 22: Network is unreachable

From what I can see, this seems to depend on a pathology not universally available even in IPv4.

> Another test you should do to measure the usefulness of this proposal is see how long it takes and your opinion afterwards of how hard or easy it is to type or cut and paste "fd00:db8::1" vs "1::1"…

I'm fine with it. If you're doing it more than 6 times, that's what DNS is for.

> Using a ULA doesn't really work at all. It only adds another address to the host, rather than many. A properly formed ULA is hard to type and remember. It's far less user friendly than the short la…

The same is true with loopback except on Linux as near as I can tell.

> Can you define the threshold of "fundamentally changed" for me?

Requiring a modification to every existing IPv6 stack in the wild which could be
incorporated into software dependencies which would render existing stacks unexpectedly
obsolete.

> I don't consider this to be a fundamental change. It is adding another loopback prefix, which operates the same as the existing one, just with a shorter prefix length. It is adding values to the so…

So you want to force everyone to update their IPv6 stack on every host, router, switch, etc. just so you can save some typing?

You're doing a very good job cementing my opposition here.

> My definition of a fundamental change would be to do something like change the change the size of the IPv6 address, or reorder the fields in the IPv6 header.

That would be a drastic change, indeed. This is less drastic, but it would make current IPv6 stacks incompatible with the protocol definition.

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Feb 2013 12:33:59 -0800 (PST)

----- Original Message -----
> Sent: Wednesday, 13 February 2013 6:59 AM
>>  The random bit is the hard bit to remember and type. I don't think 
> you're thinking enough about how it is to use, you're only thinking 
> about how hard it is to configure. The time and effort to configure something is 
> usually minimal compared to the amount of time and effort spent while it is 
> being used.
>> 
> 

RFC4193 does. It's not a ULA if it doesn't, it's been made a site-local. See RFC3879 for the problems with them and your non-random ULA.

>>  No, that's bad, as it is a ULA prefix which doesn't have a random 
> component. Add the random component (if you aren't lazy), and it then 
> becomes hard to remember and type.
>> 
> 
> Why is it bad that it doesn't have a random component? If it's in a 
> development test lab, it's not like it's at risk of corporate merger 
> conflicts, etc.
> 

See slide 26.

http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf

>>  I'm starting to wonder if you've actually read the draft. The 
> intention is that it is that the larger loopback prefix automatically configured 
> at system initialisation, as ::1/128 and 127/8 currently are. There is a whole 
> section on automatic address assignment and configuration.
> 

That's incorrect.

 RFC1122, "Requirements for Internet Hosts -- Communication Layers", specifically the <any> in

"(g) { 127, <any> }
Internal host loopback address.  Addresses of this form MUST NOT appear outside a host."

> 5 packets transmitted, 0 packets received, 100.0% packet loss

So MacOS isn't compliant with RFC1122.

>>  Another test you should do to measure the usefulness of this proposal is 
> see how long it takes and your opinion afterwards of how hard or easy it is to 
> type or cut and paste "fd00:db8::1" vs "1::1" a reasonable 
> number of times e.g. 6 times.
>> 
> 

That's an option, for applications that use DNS to resolve addresses. There are applications that need to deal with addresses directly, such as mine, due to their nature and purpose.

>> 
>>  Using a ULA doesn't really work at all. It only adds another address to 
> the host, rather than many. A properly formed ULA is hard to type and remember. 
> It's far less user friendly than the short larger loopback prefix I'm 
> proposing. This is based on my experience, as I've used a ULA for the 
> purpose of trying to increase the number of loopback IPv6 addresses.
>> 
> 

Windows 7 also behaves this way, as it complies with RFC1122.

>>  I don't consider this to be a fundamental change. It is adding another 
> loopback prefix, which operates the same as the existing one, just with a 
> shorter prefix length. It is adding values to the source and destination address 
> selection policy, which is already possible to do because it's been designed 
> that way. I'm quite confident that it is going to be no more than 10 lines, 
> and probably closer to 5 additional lines of code in a stack for a host 
> implementation that only supports a single loopback interface. That's code 
> change size closer to the size of bug fixes than additional functionality.
>> 
> 
> So you want to force everyone to update their IPv6 stack on every host, router, 
> switch, etc. just so you can save some typing?
> 

The IETF (and I) can't force anything. If it's useful, it'll be implemented.

> You're doing a very good job cementing my opposition here.

You seem to like doing things the hard way. My view is computers should do things automatically for people so that people can get on with more valuable things. Developers should be cutting code instead of setting up development environments, or waiting for system administrators to set up the development environment for them.

>>  My definition of a fundamental change would be to do something like change 
> the change the size of the IPv6 address, or reorder the fields in the IPv6 
> header.
>> 
> 
> That would be a drastic change, indeed. This is less drastic, but it would make 
> current IPv6 stacks incompatible with the protocol definition.
> 

I don't get this. 1::/32 is not currently used for anything, so using it is not going to make it incompatible with anything. Using other prefixes for purposes that they weren't designed for, such as a ULA as a loopback, has far greater risk of creating incompatibility. 

>>>  strikes me as not having much value.

You don't seem to be placing any value convenience. Does your car have an automatic transmission? Do you have a dishwasher? Do you go to restaurants? All of those things only exist because humans place value on the convenience of not manually changing gears, not manually washing dishes, and not cooking at home when we could. Why have to do something manually when a computer could do it automatically for you?
  
>>>>>>  The Draft does cover why ULA is thought to not be a 
> sufficient 
>>>  solution,
>>>>>>        A Unique Local IPv6 Unicast Address (ULA) prefix 
> [RFC4193] 
>>>  could be
>>>>>>        used to increase the number of addresses available on 
> the 
>>>  local host.
>>>>>>        configured at least once by a system administrator or 
> 
>>>  operator.
>>>>>>        assigned to the local host would not be prevented 
> from leaving 
>>>  the
>>>>>>        host, and access may not be limited to the local 
> host.  A ULA 
>>>  prefix
>>>>>>        would not be well known, and would not be convenient 
> to 
>>>  remember and
>>>>>>        type without violating the randomness requirements of 
> the 
>>>  Global ID

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Feb 2013 16:18:08 -0800

> RFC4193 does. It's not a ULA if it doesn't, it's been made a site-local. See RFC3879 for the problems with them and your non-random ULA.

Which is irrelevant to the loopback scenario you have described…

> http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf

Which does not apply to use on a loopback interface.

> Internal host loopback address.  Addresses of this form MUST NOT appear outside a host."

Yes, it requires that you not have addresses within 127.0.0.0/8 appear outside of the host. It does
not require the host to answer or auto configure all of the 127.0.0.0/8 addresses on its loopback
interface and, indeed, most hosts do NOT auto configure other than 127.0.0.1.

> So MacOS isn't compliant with RFC1122.

How do you figure that? You'll need to be more specific.

> That's an option, for applications that use DNS to resolve addresses. There are applications that need to deal with addresses directly, such as mine, due to their nature and purpose.

Then use a configuration file or whatever. There are lots of alternatives to repeatedly typing in addresses.
(command-line aliases come to mind as an example).

> Windows 7 also behaves this way, as it complies with RFC1122.

Nothing I found in RFC 1122 requires this, so if you think something does, you'll
need to point it out.

I know for a fact that several Cisco switches did not. For example, they used to use
127.0.0.<slot number> as a convenient hack for connections across the backplane
to the IP stack running on IP-aware blades such as RSMs.

> The IETF (and I) can't force anything. If it's useful, it'll be implemented.

IMHO, it's not all that useful and making it a stack requirement would lead to one of two bad situations:

1.	Development resources would be taken away from tasks that matter.
or
2.	Increasing divergence between the implemented stacks and the documented standards.

> You seem to like doing things the hard way. My view is computers should do things automatically for people so that people can get on with more valuable things. Developers should be cutting code ins…

Actually, I do not. However, I do not believe in using the entire IP stack development community as a workforce to save me a little bit of typing which, as near as I can tell is all that this proposal would accomplish.

The functionality you seek is available using ULA. The issues you cite with ULA would not apply to loopback usage. The functionality that you attribute to RFC 1122 isn't (as near as I can tell) actually codified into RFC 1122 (I don't see how requiring that an address range not appear outside of a host requires that host to accept all packets to any address in said range, which is what you are claiming).

> I don't get this. 1::/32 is not currently used for anything, so using it is not going to make it incompatible with anything. Using other prefixes for purposes that they weren't designed for, such a…

If you add this as a required stack feature, stacks which don't implement the feature are no longer compliant.

> You don't seem to be placing any value convenience. Does your car have an automatic transmission? Do you have a dishwasher? Do you go to restaurants? All of those things only exist because humans p…

I place tremendous value on convenience. My car does not have a traditional automatic transmission, my car has an ECVT transmission. If I were buying a car, I would actually prefer a manual transmission because I prefer the greater control flexibility and shifting precision afforded by a manual transmission.

Yes, I go to restaurants.

There are many equally automatic solutions to your problem already available without involving the entire body of protocol developers and the IETF in the process.

Owen

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Feb 2013 16:51:49 -0800 (PST)

Owen, I've pretty much come to the conclusion that you haven't read my draft, as the issues you are raising are discussed in it. If that is the case, you are wasting both my time and your time. So please read it. If you disagree with the text, then read the relevant sections of the references I've provided. Only then will I bother further engaging with you. I don't want to spend time rehashing points I've discussed in the draft on this emailing list, just because you haven't bothered reading the draft.

----- Original Message -----
> Sent: Wednesday, 13 February 2013 11:18 AM
>>>  Subject: Re: [v6ops] New Version Notification for 
>>>  Nothing requires you to use random for this purpose. Use fd00::/64 for 
> all 
>>>  anyone cares.
>>>   
>> 
>>  RFC4193 does. It's not a ULA if it doesn't, it's been made a 
> site-local. See RFC3879 for the problems with them and your non-random ULA.
>> 
> 
>>>>>  anything you want inside of that to provide a /64 for your 
> development 
>>>  purpose.
>>>>> 
>>>>>  What's more cumbersome about picking something (even 
> fd00::/64, if 
>>>  you want) 
>>>> 
>>>>>  for development than having some other prefix you have to 
> configure 
>>>  assigned by 
>>>> 
>>>>>  the IETF.
>>>> 
>>>>>>  This proposal also takes the opportunity to introduce 
> IPv4-like 
>>>  handling of 
>>>>>  loopback IPv6 packets so that future functions similar to the 
> use in 
>>>  RFC4379 
>>>>>  have a native IPv6 address space to use, rather than using 
> 127/8 within 
>>>  an IPv6 
>>>>>  prefix.
>>>>> 
>>>>>  In my (admittedly limited) testing, putting a /64 of ULA on the 
> 
>>>  loopback 
>>>>>  interface did just that, so I'm not sure what it is that 
> you feel 
>>>  is 
>>>>>  missing.
>>>>>   
>>>> 
>>>>  All addresses within 127/8 are valid and available on the host, 
> where as 
>>>  with your ULA, only 1 is.
>>>> 
>>>>  e.g.
>>>> 
>>>> 
>>>>  The authenticity of host '127.1.2.3 (127.1.2.3)' can't 
> be 
>>>  established.
>>>> 
>>>  From what I can see, this seems to depend on a pathology not 
> universally 
>>>  available even in IPv4.
>>> 
>>>  I'm fine with it. If you're doing it more than 6 times, 
> that's what 
>>>  DNS is for.
>>>   
>> 
>>  That's an option, for applications that use DNS to resolve addresses. 
> There are applications that need to deal with addresses directly, such as mine, 
> due to their nature and purpose.
> 
>>>>>>>  Note, I don't know the answer, but I'm leaning 
> heavily 
>>>  towards, 
>>>>> 
>>>>>>>  "no."
>>>>>>> 
>>>>>>>  Primarily because we're asking people to deploy 
> this 
>>>  protocol for 
>>>>>>>  real-world scenarios, and we already have a pretty wide 
> 
>>>  divergence in 
>>>>>>>  the latest state of the standards vs. the oldest 
> working 
>>>  deployed base. 
>>>>> 
>>>>>>>  Widening that gap should only be done for truly 
> critical 
>>>  changes, and 
>>>>>>>  Put more simply, at some point we have to stop 
> tinkering with 
>>>  the plane 
>>>>> 
>>>>>>>  while it's in the air.
>>>>>>>   
>>>>>> 
>>>>>  the sky"). I don't see how that will be the case. 
> Deploying a 
>>>  new 
>>>>>  loopback related functions of existing IPv6 implementations. It 
> is not 
>>>  much more 
>>>>>  The implication is that you are requesting to once again 
> obsolete all 
>>>  existing 
>>>>>  implementations in favor of requiring deploying another 
> fundamentally 
>>>  changed 
>>>>>  IPv6 stack.
>>>> 
>>>  incorporated into software dependencies which would render existing 
> stacks 
>>>  unexpectedly
>>>  obsolete.
>>> 
>>  You seem to like doing things the hard way. My view is computers should do 
> things automatically for people so that people can get on with more valuable 
> things. Developers should be cutting code instead of setting up development 
> environments, or waiting for system administrators to set up the development 
> environment for them.
>> 
> 
> Actually, I do not. However, I do not believe in using the entire IP stack 
> development community as a workforce to save me a little bit of typing which, as 
> near as I can tell is all that this proposal would accomplish.
> 
> The functionality you seek is available using ULA. The issues you cite with ULA 
> would not apply to loopback usage. The functionality that you attribute to RFC 
> 1122 isn't (as near as I can tell) actually codified into RFC 1122 (I 
> don't see how requiring that an address range not appear outside of a host 
> requires that host to accept all packets to any address in said range, which is 
> what you are claiming).
> 
>>  I don't get this. 1::/32 is not currently used for anything, so using 
> it is not going to make it incompatible with anything. Using other prefixes for 
> purposes that they weren't designed for, such as a ULA as a loopback, has 
> far greater risk of creating incompatibility. 
> 
>>>>>  justify such a decision and IMHO, at this point, just to make 
> it 
>>>  "less 
>>>>>  cumbersome" than putting (a) ULA address(es) on the 
> loopback 
>>>  interface 
>>  You don't seem to be placing any value convenience. Does your car have 
> an automatic transmission? Do you have a dishwasher? Do you go to restaurants? 
> All of those things only exist because humans place value on the convenience of 
> not manually changing gears, not manually washing dishes, and not cooking at 
> home when we could. Why have to do something manually when a computer could do 
> it automatically for you?
>>   
> 
> I place tremendous value on convenience. My car does not have a traditional 
> automatic transmission, my car has an ECVT transmission. If I were buying a car, 
> I would actually prefer a manual transmission because I prefer the greater 
> control flexibility and shifting precision afforded by a manual transmission.
> 
> There are many equally automatic solutions to your problem already available 
> without involving the entire body of protocol developers and the IETF in the 
> process.
> 
> Owen
> 
>>>>>  Owen
>>>>> 
>>>>>>   
>>>>>> 
>>>>>>  Regards,
>>>>>>  Mark.
>>>>>> 
>>>>>> 
>>>>>>>  Doug
>>>>>>> 
>>>>>>> 
>>>>>>>>>  Perhaps I'm not very bright, but is there 
> any 
>>>  reason ULA 
>>>>>>>  couldn't be
>>>>>>>>         However this prefix would need to be 
> manually 
>>>  generated and
>>>>>>>>         Without additonal configuration, traffic 
> towards 
>>>  addresses not
>>>>>>>>>>  Here is a new version of my IPv6 larger 
> loopback 
>>>  prefix 
>>>>>  draft.
>>>>>>>>>>  o  default address selection precedence and 
> label 
>>>  values
>>>>>>>>>>  My thanks to Bill Atwood, Matts Kallioniemi 
> and 
>>>  Tina Tsou 
>>>>>  for their

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Feb 2013 17:46:09 -0800

I had actually read it, but, since you insist…

1.
	Under IPv4, the 127/8 loopback prefix [RFC1122] provides many
   addresses that can be used to run multiple instances of an
   application on the same port, while also limiting access to the local
   host.

RFC1122 provides that 127/8 cannot appear outside of a host. It does not require that the host process all addresses within 127/8 as you describe.

2.
Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a
   single address.  Multiple application instances using the same port,
   bound to different loopback addresses, is not possible.

Is not true. You can configure additional addresses on to the loopback interface as desired and use them just as you would additional addresses from the 127/8 address range. Since RFC1122 does not require that the host treat all these addresses identically as you assume, there is no difference between the current standards in IPv6 and the current standards in IPv4 except that IPv4 sets aside a dedicated 16.7 million host addresses for this purpose (of which only one is utilized in most cases) and IPv6 sets  aside 1. However, you are free to assign any GUA or ULA prefix to the IPv6 loopback and use it in the same manner as you are currently using the other 127/8 addresses.

3.

Since the communication of this prefix in this case would not be expected to extend beyond the host, the
only requirement is that the ULA prefix chosen not conflict with one that the host is expected to need to reach outside of the host. As such, fd00::/48 is a perfectly viable candidate in the vast majority of cases as it is very unlikely to conflict with a randomly chosen routable prefix that follows the standards in RFC4193.

The Global ID component of  a ULA prefix is intended to avoid conflicts in the results of M&A, etc. Since this would be host-local addressing and not even have site-scope, use of a known non-conflicting ULA address is perfectly feasible. fd00::/48 is very unlikely to conflict (1 in 2^40 or < 0.000,000,000,1% or  <1 in 1e12).

4.
2.  Larger Loopback Prefix Requirements

   A new larger loopback prefix should attempt to satisfy all of the
   following requirements.  It should:

   o  be a well known prefix,

   o  be within an existing special purpose prefix, such as 0000::/8
      (the parent prefix of the current IPv6 loopback address),

   o  be easy for a human to remember,

   o  be easy for a human to type,

   o  cover the existing loopback prefix,

   o  support 64 bit Interface Identifiers,

   o  provide a large number of /64 subnets.

I believe that fd00::/48 could do what you describe:

	1.	I question the need for it to be well known. As long as it is well known within
		the scope of the intended use, I think that suffices for the use cases you have
		described.

		fd00::/48 could easily meet that test.

	2.	fd00::/48 is within the existing ULA special purpose prefix.
	3.	fd00::/48 is very easy for a human to remember.
	4.	fd00::/48 is very easy for a human to type.
	5.	Please justify your claim that it should encompass the existing loopback address.
	6.	fd00::/48 supports 64 bit IIDs.
	7.	fd00::/48 provides 65,536 /64 subnets. Is there some reason you think this is insufficient?
		This is a total of 4 billion times 16.7 million times as many host addresses as were provided
		in the IPv4 loopback.

		It is 1/256th as many networks as IPv4 provided loopback hosts.

5.
3.  Proposed Larger Loopback Prefix

   Ideally, the prefix length of ::1/128 could be shortened, resulting
   in a larger loopback prefix such as ::/48.  However, if the existing
   loopback prefix length is shortened enough to satisfy all of the
   larger loopback prefix requirements, it would then cover the IPv4
   Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use
   described in [RFC4038].

   Giving up the requirement of covering the existing loopback prefix,
   the proposed larger loopback prefix is:

So why not simply delete this from the requirements list as you've failed to
provide any justification for said requirement anyway.

Smith                    Expires August 15, 2013                [Page 4]
 
Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013

      0001:0000:0000:0000:0000:0000:0000:0000/32

   or concisely,

      1::/32

   This prefix satisfies all remaining larger loopback prefix
   requirements.

I think this is a terrible choice of location. It pretty much maximizes the fragmentation damage that can be done by the choice of prefix. :1::/32 would at least be the first /32 available. As I've stated, a locally chosen address such as fd00::/48 (or whatever selection of chosen ULA space meets local requirements) is equally viable IMHO.

6.
Allocating a /32 prefix for the loopback function may seem excessive,
   as a /48 length prefix would satisfy the larger loopback prefix
   requirements.  However, within the parent 0000::/8 special purpose
   prefix, there are approximately 16 million /32 prefixes, so a single
   /32 for the larger loopback prefix is easily afforded.  A /32 larger
   loopback prefix will satisfy all current and likely future uses of
   the loopback function.

Allocating a /32 is absurdly excessive and just because we can does not strike me as anything remotely resembling an argument that we should.

4.  Address Assignment and Configuration

 Consistent with the IPv6 addressing model [RFC4291], each address
   within the larger loopback prefix is associated with one of the
   node's interfaces, although not necessarily the same interface for
   all addresses.  This means that the node acts as though all addresses
   within the larger loopback prefix have been configured on one or more
   interfaces.  Applications will accept packets destined to any of the
   larger loopback prefix addresses, unless the application is bound to
   specific larger loopback addresses.  Typically the addresses will be
   logically assigned to one or more virtual "loopback" interfaces,
   which locally returns or loops outgoing packets back to the same node
   that originated the packets.

I believe you have misread and conflated RFC4291 and RFC1122 with regards to how loopback
addresses function.

Unless I am mistaken, there is no requirement in RFC1122 that a node answer all addresses within 127/8.

Some nodes may support more than one loopback interface.  These
   subsequent loopback interfaces, when initialised, should be assigned

Smith                    Expires August 15, 2013                [Page 5]
 
Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013

   a larger loopback /64 prefix locally unique within the node.  All
   addresses within the assigned /64 are logically assigned to the
   interface.  Additionally, the ":1" address for the subnet should be
   configured on the loopback interface, making it visible to a system
   operator or user.

This would, indeed, be new functionality. I am not convinced of any value to having that functionality and it is radically different from any required functionality in IPv4 today. In IPv4, hosts which support multiple loopbacks have no default address or range on the subsequent loopback interfaces.

If you cannot justify a need for this functionality, I see no point in advancing it as a standard.

It should be possible for an operator to remove these automatically
   configured loopback addresses.  It should also be possible for an
   operator to configure further loopback addresses from within the
   assigned /64, or addresses from other parts of the larger loopback
   prefix, including other /64s assigned to other loopback interfaces.
   Other addresses within the assigned /64(s) would continue to be
   logically assigned to the subsequent loopback interface.
   Configuration of addresses is for operational visibility and
   convenience, and does not change the behaviour of non-visible
   logically assigned addresses.

If you're going to do this, then I would argue that it "must" be possible for an operator to remove…

The rest of what you suggest strikes me as being a kernel routing hairball of unnecessarily large
proportion and likely to engender more bugs than functionality.

------

This covers the first 6 pages (approximately half of the draft). I'm not going to take the time to write up the problems in the rest of the draft at this point because the above are, IMHO, more than sufficient reason to oppose adoption.

Owen

---

From: Doug Barton <[email-masked]>
Date: Tue, 12 Feb 2013 23:00:03 -0800

FWIW, I had also read the draft, and my analysis is identical to Owen's, 
albeit he stated it below much better, and much more thoroughly than I 
would have.

I'm opposed to the group adopting the draft, and opposed to its 
publication in any form.

Doug

On 02/12/2013 05:46 PM, Owen DeLong wrote:
> Under IPv4, the 127/8 loopback prefix [RFC1122
> <http://tools.ietf.org/html/rfc1122>] provides many
>
> RFC1122 provides that 127/8 cannot appear outside of a host. It does not
> require that the host process all addresses within 127/8 as you describe.
>
> 2.
>
> Under IPv6, the ::1/128 loopback prefix [RFC4291  <http://tools.ietf.org/html/rfc4291>] only provides a
> Is not true. You can configure additional addresses on to the loopback
> interface as desired and use them just as you would additional addresses
> from the 127/8 address range. Since RFC1122 does not require that the
> host treat all these addresses identically as you assume, there is no
> difference between the current standards in IPv6 and the current
> standards in IPv4 except that IPv4 sets aside a dedicated 16.7 million
> host addresses for this purpose (of which only one is utilized in most
> cases) and IPv6 sets  aside 1. However, you are free to assign any GUA
> or ULA prefix to the IPv6 loopback and use it in the same manner as you
> are currently using the other 127/8 addresses.
>
> 3.
>
>   A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193  <http://tools.ietf.org/html/rfc4193>] could be
> only requirement is that the ULA prefix chosen not conflict with one
> that the host is expected to need to reach outside of the host. As such,
> fd00::/48 is a perfectly viable candidate in the vast majority of cases
> as it is very unlikely to conflict with a randomly chosen routable
> prefix that follows the standards in RFC4193.
>
> The Global ID component of  a ULA prefix is intended to avoid conflicts
> in the results of M&A, etc. Since this would be host-local addressing
> and not even have site-scope, use of a known non-conflicting ULA address
> is perfectly feasible. fd00::/48 is very unlikely to conflict (1 in 2^40
> or < 0.000,000,000,1% or  <1 in 1e12).
>
> 4.
>
>
>     2
>     <http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-03#section-2>.
>     Larger Loopback Prefix Requirements
>
>
>
> 1.I question the need for it to be well known. As long as it is well
> known within
> 2.fd00::/48 is within the existing ULA special purpose prefix.
> 3.fd00::/48 is very easy for a human to remember.
> 4.fd00::/48 is very easy for a human to type.
> 5.Please justify your claim that it should encompass the existing
> loopback address.
> 6.fd00::/48 supports 64 bit IIDs.
> 7.fd00::/48 provides 65,536 /64 subnets. Is there some reason you think
> this is insufficient?
>     3
>     <http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-03#section-3>.
>     Proposed Larger Loopback Prefix
>
>
>
>     described in [RFC4038  <http://tools.ietf.org/html/rfc4038>].
>
>     <http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-03#page-5>
> I think this is a terrible choice of location. It pretty much maximizes
> the fragmentation damage that can be done by the choice of prefix.
> :1::/32 would at least be the first /32 available. As I've stated, a
> locally chosen address such as fd00::/48 (or whatever selection of
> chosen ULA space meets local requirements) is equally viable IMHO.
>
> 6.
>
> Allocating a /32 is absurdly excessive and just because we can does not
> strike me as anything remotely resembling an argument that we should.
>
>
>     4
>     <http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-03#section-4>.
>     Address Assignment and Configuration
>
>
>
>       Consistent with the IPv6 addressing model [RFC4291  <http://tools.ietf.org/html/rfc4291>], each address
>     <http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-03#page-6>
> This would, indeed, be new functionality. I am not convinced of any
> value to having that functionality and it is radically different from
> any required functionality in IPv4 today. In IPv4, hosts which support
> multiple loopbacks have no default address or range on the subsequent
> loopback interfaces.
>
> This covers the first 6 pages (approximately half of the draft). I'm not
> going to take the time to write up the problems in the rest of the draft
> at this point because the above are, IMHO, more than sufficient reason
> to oppose adoption.
>
> Owen
>
> On Feb 12, 2013, at 4:18 PM, Owen DeLong <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>
>> On Feb 12, 2013, at 12:33 PM, Mark Smith <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>>
>>>
>>>
>>>
>>>> From: Owen DeLong <[email-masked] <mailto:[email-masked]>>
>>>> To: Mark Smith <[email-masked]
>>>> <mailto:[email-masked]>>
>>>> Cc: Doug Barton <[email-masked] <mailto:[email-masked]>>;
>>>> "[email-masked] <mailto:[email-masked]>" <[email-masked]
>>>> <mailto:[email-masked]>>
>>>> Nothing requires you to use random for this purpose. Use fd00::/64
>>>> for all
>>>> anyone cares.
>>>>
>>>
>>>>>> have a native IPv6 address space to use, rather than using 127/8
>>>>>> within
>>>> an IPv6
>>>>>> prefix.
>>>>>>
>>> There are applications that need to deal with addresses directly,
>>> such as mine, due to their nature and purpose.
>>
>> Then use a configuration file or whatever. There are lots of
>> alternatives to repeatedly typing in addresses.
>>>>>> loopback related functions of existing IPv6 implementations. It is
>>>>>> not
>>>> much more
>> 1.Development resources would be taken away from tasks that matter.
>> or
>> 2.Increasing divergence between the implemented stacks and the
>> documented standards.
>>
>>
>>> You seem to like doing things the hard way. My view is computers
>>> should do things automatically for people so that people can get on
>>> with more valuable things. Developers should be cutting code instead
>>> of setting up development environments, or waiting for system
>>> administrators to set up the development environment for them.
>>>
>>
>> Actually, I do not. However, I do not believe in using the entire IP
>> stack development community as a workforce to save me a little bit of
>> typing which, as near as I can tell is all that this proposal would
>> accomplish.
>>
>> The functionality you seek is available using ULA. The issues you cite
>> with ULA would not apply to loopback usage. The functionality that you
>> attribute to RFC 1122 isn't (as near as I can tell) actually codified
>> into RFC 1122 (I don't see how requiring that an address range not
>> appear outside of a host requires that host to accept all packets to
>> any address in said range, which is what you are claiming).
>>
>>> it is not going to make it incompatible with anything. Using other
>>> prefixes for purposes that they weren't designed for, such as a ULA
>>> as a loopback, has far greater risk of creating incompatibility.
>>
>> If you add this as a required stack feature, stacks which don't
>> implement the feature are no longer compliant.
>>
>>>
>>> You don't seem to be placing any value convenience. Does your car
>>> have an automatic transmission? Do you have a dishwasher? Do you go
>>> to restaurants? All of those things only exist because humans place
>>> value on the convenience of not manually changing gears, not manually
>>> washing dishes, and not cooking at home when we could. Why have to do
>>> something manually when a computer could do it automatically for you?
>>>
>>
>> I place tremendous value on convenience. My car does not have a
>> traditional automatic transmission, my car has an ECVT transmission.
>> If I were buying a car, I would actually prefer a manual transmission
>> because I prefer the greater control flexibility and shifting
>> precision afforded by a manual transmission.
>>
>> There are many equally automatic solutions to your problem already
>> available without involving the entire body of protocol developers and
>> the IETF in the process.
>>
>> Owen
>>
>>>>>> Owen
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mark.
>>>>>>>
>>>>>>>
>>>>>>>> Doug
>>>>>>>>
>>>>>>>>
>>>>>>>>>> On Feb 11, 2013, at 12:20 , Mark Smith
>>>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Feb 2013 00:09:52 -0800 (PST)

>________________________________
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Wednesday, 13 February 2013 12:46 PM

I think it is an obligation of being a member of this mailing list if you are going to disagree with parts of an ID publicly. 

>addresses that can be used to run multiple instances of an application on the same port, while also limiting access to the local host.
>
>

You're right it doesn't say that. It is common convention to do so, and has been a useful one to me and others. I will change the text to reflect that it is a common convention.

>
>2.
>Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a single address.  Multiple application instances using the same port, bound to different loopback addresses, is not possible. 
>
>

I think you're choosing to misread this two sentence paragraph. Normal English convention is that sentences subsequent to the first in a paragraph are in the context of the topic described by the first sentence. Specifying the topic of a paragraph in each sentence is redundant. The second sentence is describing a limitation with the ::1/128 loopback prefix, which I'm confident is obvious to most English speakers. One of my past reviewers isn't a native English speaker, and they have had no trouble with that paragraph.

GUAs and ULAs aren't loopback prefixes (see RFC4291 and RFC4193), so my statement is true.

>
>3.
>A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be used to increase the number of addresses available on the local host. However this prefix would need to be manually generated and configured at least once by a system administrator or operator. Without additonal configuration, traffic towards addresses not assigned to the local host would not be prevented from leaving the host, and access may not be limited to the local host.  A ULA prefix would not be well known, and would not be convenient to remember and type without violating the randomness requirements of the Global ID component of a ULA prefix.
>
>

So what would happen if you had an IPv6 CPE that was announcing fd00::/64 in it's RAs (slide 26 ...), and you configured fd00::/48 or fd00::/64 on one of your loopback interfaces?

>
>4.
>2.  Larger Loopback Prefix Requirements A new larger loopback prefix should attempt to satisfy all of the following requirements.  It should: o  be a well known prefix, o  be within an existing special purpose prefix, such as 0000::/8 (the parent prefix of the current IPv6 loopback address), o  be easy for a human to remember, o  be easy for a human to type, o  cover the existing loopback prefix, o  support 64 bit Interface Identifiers, o  provide a large number of /64 subnets. 
>
>
>1.I question the need for it to be well known. As long as it is well known within

Well known makes it easy to add to ACLs. Well known makes it easy to remember. Well known means it is the same on all hosts.

People will even turn an "unusable definition of the loopback address", used to "encourage use	of officially-assigned addresses", into the well known loopback address.

http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8603.mm.www/0184.html

>fd00::/48 could easily meet that test.

And fails to comply with the RFC that defines the address space it falls within. From RFC4193:
" The allocation of Global IDs is pseudo-random [RANDOM].  They MUST NOT be assigned sequentially or with well-known numbers."
"Locally assigned Global IDs MUST be generated with a pseudo-random

algorithm consistent with [RANDOM]."

So your proposal violates that RFC, and therefore you would need to write an ID changing it to support your use of the Global ID zero value.

>5.Please justify your claim that it should encompass the existing loopback address.

I'd have thought it'd be obvious that expanding the existing prefix would have been better if possible. I'd have thought this text would convey that.

"Ideally, the prefix length of ::1/128 could be shortened, resulting in a larger loopback prefix such as ::/48.  However, if the existing loopback prefix length is shortened enough to satisfy all of the larger loopback prefix requirements, it would then cover the IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use described in [RFC4038]."

>7.fd00::/48 provides 65,536 /64 subnets. Is there some reason you think this is insufficient?

It is quite adequate, and the size I proposed in the first two drafts. However, under 0000::/8, it's possible to make it a /32, because their are 16 million of them. Since this draft is revisiting the original ::1/128 decision, why not make every attempt that can be easily afforded to avoid revisiting the IPv6 loopback prefix the 3rd time. "More than enough" is better than "just enough" when cheap enough, as it saves coming back for more. 

>3.  Proposed Larger Loopback Prefix Ideally, the prefix length of ::1/128 could be shortened, resulting in a larger loopback prefix such as ::/48.  However, if the existing loopback prefix length is shortened enough to satisfy all of the larger loopback prefix requirements, it would then cover the IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use described in [RFC4038]. Giving up the requirement of covering the existing loopback prefix, the proposed larger loopback prefix is: 
>
>
>

Requirementlists define both wants and needs. It's there because more than once people have asked why not just shorten the prefix length of the existing prefix.

> Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013 0001:0000:0000:0000:0000:0000:0000:0000/32 or concisely, 1::/32 This prefix satisfies all remaining larger loopback prefix requirements.
>
>

The goal was the shortest thing to type, and I don't think fragmentation matters within 0000::/8. I think people will commonly forget the colon on the front of :1::/32, or mix up where the two contiguous colons are e.g. they'll type ::1:/32.

>
>6.
>Allocating a /32 prefix for the loopback function may seem excessive, as a /48 length prefix would satisfy the larger loopback prefix requirements.  However, within the parent 0000::/8 special purpose prefix, there are approximately 16 million /32 prefixes, so a single /32 for the larger loopback prefix is easily afforded.  A /32 larger loopback prefix will satisfy all current and likely future uses of the loopback function.
>
>

So you're saying that you can think of better uses for the 16 million /32s within 0000::/8, such that just one can't be used for this purpose? What are some of your better uses?

>Consistent with the IPv6 addressing model [RFC4291], each address within the larger loopback prefix is associated with one of the node's interfaces, although not necessarily the same interface for all addresses.  This means that the node acts as though all addresses within the larger loopback prefix have been configured on one or more interfaces.  Applications will accept packets destined to any of the larger loopback prefix addresses, unless the application is bound to specific larger loopback addresses.  Typically the addresses will be logically assigned to one or more virtual "loopback" interfaces, which locally returns or loops outgoing packets back to the same node that originated the packets.
>
>
>
>
>
>

This is specifying the address assignment and configuration scheme for the proposed larger loopback prefix. You have misread and misunderstood this text.

>Some nodes may support more than one loopback interface.  These subsequent loopback interfaces, when initialised, should be assigned Smith                    Expires August 15, 2013                [Page 5] 
> Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013 a larger loopback /64 prefix locally unique within the node.  All addresses within the assigned /64 are logically assigned to the interface.  Additionally, the ":1" address for the subnet should be configured on the loopback interface, making it visible to a system operator or user.
>
>

Right. The goal here is to take something useful in IPv4 that doesn't exist in IPv6, and then to also see if there are opportunities to make further improvements. This is not a literal copy of IPv4 functionality into IPv6. Changes to fix limitations are also opportunities to make improvements.

>If you cannot justify a need for this functionality, I see no point in advancing it as a standard.

I have justified it, in Abstract and the Introduction. You might not believe there is a problem to solve, but that doesn't mean that other people don't, and that they haven't experienced a problem. In addition to myself, Erik Kline and Vijayrajan Ranganathan have encountered situations where more IPv6 loopback addresses would be useful:

http://www.ietf.org/mail-archive/web/v6ops/current/msg14815.html

http://www.ietf.org/mail-archive/web/ipv6/current/msg10882.html

Here is Erik, back in 2009, describing the exact scenario that I've described in the Abstract and Intro.

http://www.ietf.org/mail-archive/web/ipv6/current/msg11018.html

>
>It should be possible for an operator to remove these automatically configured loopback addresses.  It should also be possible for an operator to configure further loopback addresses from within the assigned /64, or addresses from other parts of the larger loopback prefix, including other /64s assigned to other loopback interfaces. Other addresses within the assigned /64(s) would continue to be logically assigned to the subsequent loopback interface. Configuration of addresses is for operational visibility and convenience, and does not change the behaviour of non-visible logically assigned addresses.
>
>

ok. I've tried to avoid being too absolute in this area because it's describing operator/system interface functionality, rather than things a compliant implementation must do.

>proportion and likely to engender more bugs than functionality.

I'm curious as to what experience you have to be able to make that judgement. Using Linux as an example IPv6 implementation, I know enough about the Linux kernel networking code that I'm pretty sure it shouldn't be too hard to make these changes.

>>2.Increasing divergence between the implemented stacks and the documented standards.
>>
>>
>>
>>>>>>>>>><[email-masked]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Hi,
>>>>>>>>>>>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Feb 2013 01:57:18 -0800

> I think it is an obligation of being a member of this mailing list if you are going to disagree with parts of an ID publicly. 

As I said, I had actually read it. In spite of your claim that I hadn't. While my subsequent post was more detailed than my previous arguments, I do not think any of my previous arguments were in any way inconsistent with the subsequent more
detailed post.

> You're right it doesn't say that. It is common convention to do so, and has been a useful one to me and others. I will change the text to reflect that it is a common convention.

I don't know how common that convention is. We've identified only 2 operating systems that actually do so as yet. I don't know what the behavior in other BSD derivatives, embedded operating systems, etc. is. Certainly it is not common enough that I would consider counting on it a good strategy for portable code.

> GUAs and ULAs aren't loopback prefixes (see RFC4291 and RFC4193), so my statement is true.

Your statement is not true. Multiple application instances using the same port bound to different loopback addresses is possible. The fact that the loopback addresses in question must be pulled from the ULA or GUA pools is irrelevant to the truth or falsehood of the statement. Once you assign an address to a loopback interface, it is by definition a loopback address whether or not it came from a "loopback prefix".

> So what would happen if you had an IPv6 CPE that was announcing fd00::/64 in it's RAs (slide 26 …), and you configured fd00::/48 or fd00::/64 on one of your loopback interfaces?
> 

You'd be unable to reach the other hosts using that prefix most likely. However, one wouldn't expect that you would do such a thing. If your router is actually using fd00::/64, you'd want to use something else for the loopback. Fortunately, you have 40 bits worth (more than a trillion) other prefixes to choose from.

> Well known makes it easy to add to ACLs. Well known makes it easy to remember. Well known means it is the same on all hosts.

If it's a loopback, what's the point of putting it in ACLs? Since the packets shouldn't leave the host, there's not much utility to ACLs.

As long as it's well known within the context (i.e. workgroup, company, site, whatever administrative boundary you
decide is appropriate under the circumstances) it still meets those requirements anyway.

> http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8603.mm.www/0184.html

That URL leads to a rather lengthy rant about bugs in 4.2 (and 4.3) BSD which I believe were fixed many years ago.

It talks about software mistakenly choosing the loopback address as a source address when creating a reply packet in UDP. I fail to see any relevance to the current proposal other than as a possible further indication of just how bad an idea this actually is, since the closest connection that comes to mind is the probability of implementing this draft leading to the introduction of similar bugs.
> So your proposal violates that RFC, and therefore you would need to write an ID changing it to support your use of the Global ID zero value.

Or you sanely realize that the reason for that is the assumption that the addresses would be applied to routable interfaces and not loopbacks. Certainly an ID using fd00::/48 would be preferable to this debacle as it doesn't require any software updates and provides the same functionality.

However, as I pointed out, fd00::/48 was just an easy example. You could use a truly random ULA if you were so inclined, but you lose out on the easy to type/easy to remember features.

> I'd have thought it'd be obvious that expanding the existing prefix would have been better if possible. I'd have thought this text would convey that.

Better in what way. You still haven't actually justified this claim, you've merely told me it should be obvious.

Certainly, if it's so obvious, it shouldn't be hard to explain.

> "Ideally, the prefix length of ::1/128 could be shortened, resulting in a larger loopback prefix such as ::/48.  However, if the existing loopback prefix length is shortened enough to satisfy all o…

Yes, I read that. Restating it adds nothing to the discussion. You still haven't said anything which supports your claim that this would somehow be ideal."

> It is quite adequate, and the size I proposed in the first two drafts. However, under 0000::/8, it's possible to make it a /32, because their are 16 million of them. Since this draft is revisiting…

For that matter, it's possible to make it a /16 or a /64, but I don't see any justification for those numbers, either.

I would argue that if you can't do it in 65,536 times 18 quintillion loopback addresses, it probably won't fit in any host ever likely to be manufactured within the useful lifetime of IPv6.

OTOH, given how much we wish we could have revisited the absolutely moronic choice to waste an entire /8 on IPv4 loopbacks, going to a /32 seems likely to be equally moronic. While I personally think this is a boondoggle to begin with, if it is to be adopted, I certainly thin a /48 is so much more than enough that multiplying that mistake by 65,536 makes no sense whatsoever.

> Requirementlists define both wants and needs. It's there because more than once people have asked why not just shorten the prefix length of the existing prefix.

Interesting… That was the part I considered obvious. I still don't see any advantage to doing so vs. using space somewhere else.

> The goal was the shortest thing to type, and I don't think fragmentation matters within 0000::/8. I think people will commonly forget the colon on the front of :1::/32, or mix up where the two cont…

Good arguments against using 1::/32 as well.

> So you're saying that you can think of better uses for the 16 million /32s within 0000::/8, such that just one can't be used for this purpose? What are some of your better uses?

No, but I am saying I'm willing to bet that other better uses for the other 65,535 /48s in 1::/32 are not at all unlikely to come along.

> This is specifying the address assignment and configuration scheme for the proposed larger loopback prefix. You have misread and misunderstood this text.

No, I didn't. However, you claim "Consistent with…" and follow it with a description which is not consistent.

> Right. The goal here is to take something useful in IPv4 that doesn't exist in IPv6, and then to also see if there are opportunities to make further improvements. This is not a literal copy of IPv4…

My point is that the capability that exists in IPv4 today also exists in IPv6 already. The only difference is the pool of addresses you have to choose from for that purpose. In IPv4, you have, in addition to the global unicast, RFC-1918, and in some circumstances, link local addresses the normally unused addresses within 127/8. In IPv6, you are limited to the ULA and GUA in addition to ::1/128.

> I have justified it, in Abstract and the Introduction. You might not believe there is a problem to solve, but that doesn't mean that other people don't, and that they haven't experienced a problem.…

Your justification isn't. The problem statements you have presented so far can be solved without requiring software modifications to every IPv6 stack.

> http://www.ietf.org/mail-archive/web/ipv6/current/msg11018.html

I'm not saying your problem shouldn't be solved. I'm saying that it already has been.

> ok. I've tried to avoid being too absolute in this area because it's describing operator/system interface functionality, rather than things a compliant implementation must do.

But you don't say that a compliant implementation must. As written, your draft would allow a compliant implementation which did not allow operator removal. I consider this highly undesirable.

> I'm curious as to what experience you have to be able to make that judgement. Using Linux as an example IPv6 implementation, I know enough about the Linux kernel networking code that I'm pretty sur…

I know that most hosts today do not behave well and most routers won't even allow you to configure overlapping prefixes
and addresses on multiple interfaces. Admittedly, some of that is due to the fact that the desired behavior is not defined anywhere, which admittedly is addressed to some extent in your draft. However, even with those definitions it still strikes
me as being quite a mess both from a principle-of-least-surprise perspective as well as a complexity for the sake of
complexity perspective.

Owen

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Feb 2013 22:15:42 -0800 (PST)

So you've resorted to insults. I ignore people who resort to insults, because they've clearly run out of actual points of argument, and won't accept that other people have and can have different ones.

----- Original Message -----
> Sent: Wednesday, 13 February 2013 8:57 PM
>>  I think it is an obligation of being a member of this mailing list if you 
> are going to disagree with parts of an ID publicly. 
>> 
> 
> As I said, I had actually read it. In spite of your claim that I hadn't. 
> While my subsequent post was more detailed than my previous arguments, I do not 
> think any of my previous arguments were in any way inconsistent with the 
> subsequent more
> detailed post.
> 
>>> 
>>>  1.
>>>  addresses that can be used to run multiple instances of an application 
> on the same port, while also limiting access to the local host.
>>> 
>>> 
>>>  RFC1122 provides that 127/8 cannot appear outside of a host. It does 
> not require that the host process all addresses within 127/8 as you describe.
>>> 
>> 
>>  You're right it doesn't say that. It is common convention to do so, 
> and has been a useful one to me and others. I will change the text to reflect 
> that it is a common convention.
>> 
> 
> I don't know how common that convention is. We've identified only 2 
> operating systems that actually do so as yet. I don't know what the behavior 
> in other BSD derivatives, embedded operating systems, etc. is. Certainly it is 
> not common enough that I would consider counting on it a good strategy for 
> portable code.
> 
>>> 
>>>  2.
> single address.  Multiple application instances using the same port, bound to 
> different loopback addresses, is not possible. 
>>> 
>>> 
> interface as desired and use them just as you would additional addresses from 
> the 127/8 address range. Since RFC1122 does not require that the host treat all 
> these addresses identically as you assume, there is no difference between the 
> current standards in IPv6 and the current standards in IPv4 except that IPv4 
> sets aside a dedicated 16.7 million host addresses for this purpose (of which 
> only one is utilized in most cases) and IPv6 sets  aside 1. However, you are 
> free to assign any GUA or ULA prefix to the IPv6 loopback and use it in the same 
> manner as you are currently using the other 127/8 addresses.
>>> 
>> 
>>  I think you're choosing to misread this two sentence paragraph. Normal 
> English convention is that sentences subsequent to the first in a paragraph are 
> in the context of the topic described by the first sentence. Specifying the 
> topic of a paragraph in each sentence is redundant. The second sentence is 
> describing a limitation with the ::1/128 loopback prefix, which I'm 
> confident is obvious to most English speakers. One of my past reviewers 
> isn't a native English speaker, and they have had no trouble with that 
> paragraph.
>> 
> Your statement is not true. Multiple application instances using the same port 
> bound to different loopback addresses is possible. The fact that the loopback 
> addresses in question must be pulled from the ULA or GUA pools is irrelevant to 
> the truth or falsehood of the statement. Once you assign an address to a 
> loopback interface, it is by definition a loopback address whether or not it 
> came from a "loopback prefix".
> 
>>> 
>>>  3.
> ULA prefix.
> fd00::/48 is a perfectly viable candidate in the vast majority of cases as it is 
> very unlikely to conflict with a randomly chosen routable prefix that follows 
> the standards in RFC4193.
>>> 
>>> 
> in the results of M&A, etc. Since this would be host-local addressing and 
> not even have site-scope, use of a known non-conflicting ULA address is 
> perfectly feasible. fd00::/48 is very unlikely to conflict (1 in 2^40 or < 
> 0.000,000,000,1% or  <1 in 1e12).
>>> 
>> 
>>  So what would happen if you had an IPv6 CPE that was announcing fd00::/64 
> in it's RAs (slide 26 …), and you configured fd00::/48 or fd00::/64 on one 
> of your loopback interfaces?
>> 
> 
> You'd be unable to reach the other hosts using that prefix most likely. 
> However, one wouldn't expect that you would do such a thing. If your router 
> is actually using fd00::/64, you'd want to use something else for the 
> loopback. Fortunately, you have 40 bits worth (more than a trillion) other 
> prefixes to choose from.
> 
>>> 
>>>  4.
>>>  2.  Larger Loopback Prefix Requirements A new larger loopback prefix 
> should attempt to satisfy all of the following requirements.  It should: o  be a 
> well known prefix, o  be within an existing special purpose prefix, such as 
> 0000::/8 (the parent prefix of the current IPv6 loopback address), o  be easy 
> for a human to remember, o  be easy for a human to type, o  cover the existing 
> loopback prefix, o  support 64 bit Interface Identifiers, o  provide a large 
> number of /64 subnets. 
>>> 
>>> 
>>  Well known makes it easy to add to ACLs. Well known makes it easy to 
> remember. Well known means it is the same on all hosts.
>> 
> 
> If it's a loopback, what's the point of putting it in ACLs? Since the 
> packets shouldn't leave the host, there's not much utility to ACLs.
> 
> As long as it's well known within the context (i.e. workgroup, company, 
> site, whatever administrative boundary you
>>  People will even turn an "unusable definition of the loopback 
> address", used to "encourage use    of officially-assigned 
> addresses", into the well known loopback address.
>> 
> It talks about software mistakenly choosing the loopback address as a source 
> address when creating a reply packet in UDP. I fail to see any relevance to the 
> current proposal other than as a possible further indication of just how bad an 
> idea this actually is, since the closest connection that comes to mind is the 
> probability of implementing this draft leading to the introduction of similar 
> bugs.
>> 
>> 
>>> 
>>  " The allocation of Global IDs is pseudo-random [RANDOM].  They MUST 
> NOT be assigned sequentially or with well-known numbers."
>>  So your proposal violates that RFC, and therefore you would need to write 
> an ID changing it to support your use of the Global ID zero value.
>> 
> 
> Or you sanely realize that the reason for that is the assumption that the 
> addresses would be applied to routable interfaces and not loopbacks. Certainly 
> an ID using fd00::/48 would be preferable to this debacle as it doesn't 
> require any software updates and provides the same functionality.
> 
> However, as I pointed out, fd00::/48 was just an easy example. You could use a 
> truly random ULA if you were so inclined, but you lose out on the easy to 
> type/easy to remember features.
> 
>>> 
>>  I'd have thought it'd be obvious that expanding the existing prefix 
> would have been better if possible. I'd have thought this text would convey 
> that.
> 
> Better in what way. You still haven't actually justified this claim, 
> you've merely told me it should be obvious.
> 
>>  "Ideally, the prefix length of ::1/128 could be shortened, resulting 
> in a larger loopback prefix such as ::/48.  However, if the existing loopback 
> prefix length is shortened enough to satisfy all of the larger loopback prefix 
> requirements, it would then cover the IPv4 Mapped IPv6 Address prefix, 
> ::ffff:0.0.0.0/96, and prevent its use described in [RFC4038]."
>> 
> 
> Yes, I read that. Restating it adds nothing to the discussion. You still 
> haven't said anything which supports your claim that this would somehow be 
> ideal."
> 
>> 
>> 
>>  It is quite adequate, and the size I proposed in the first two drafts. 
> However, under 0000::/8, it's possible to make it a /32, because their are 
> 16 million of them. Since this draft is revisiting the original ::1/128 
> decision, why not make every attempt that can be easily afforded to avoid 
> revisiting the IPv6 loopback prefix the 3rd time. "More than enough" 
> is better than "just enough" when cheap enough, as it saves coming 
> back for more. 
>> 
> 
> For that matter, it's possible to make it a /16 or a /64, but I don't 
> see any justification for those numbers, either.
> 
> I would argue that if you can't do it in 65,536 times 18 quintillion 
> loopback addresses, it probably won't fit in any host ever likely to be 
> manufactured within the useful lifetime of IPv6.
> 
> OTOH, given how much we wish we could have revisited the absolutely moronic 
> choice to waste an entire /8 on IPv4 loopbacks, going to a /32 seems likely to 
> be equally moronic. While I personally think this is a boondoggle to begin with, 
> if it is to be adopted, I certainly thin a /48 is so much more than enough that 
> multiplying that mistake by 65,536 makes no sense whatsoever.
> 
>>> 
>>>  3.  Proposed Larger Loopback Prefix Ideally, the prefix length of 
> ::1/128 could be shortened, resulting in a larger loopback prefix such as 
> ::/48.  However, if the existing loopback prefix length is shortened enough to 
> satisfy all of the larger loopback prefix requirements, it would then cover the 
> IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use 
> described in [RFC4038]. Giving up the requirement of covering the existing 
> loopback prefix, the proposed larger loopback prefix is: 
>>> 
>>> 
>>> 
>>  Requirementlists define both wants and needs. It's there because more 
> than once people have asked why not just shorten the prefix length of the 
> existing prefix.
> 
> Interesting… That was the part I considered obvious. I still don't see any 
> advantage to doing so vs. using space somewhere else.
> 
>> 
>>>  Internet-Draft        A Larger IPv6 Loopback Prefix        February 
> 2013 0001:0000:0000:0000:0000:0000:0000:0000/32 or concisely, 1::/32 This prefix 
> satisfies all remaining larger loopback prefix requirements.
>>> 
>>> 
> the fragmentation damage that can be done by the choice of prefix. :1::/32 would 
> at least be the first /32 available. As I've stated, a locally chosen 
> address such as fd00::/48 (or whatever selection of chosen ULA space meets local 
> requirements) is equally viable IMHO.
>>> 
>> 
>>  The goal was the shortest thing to type, and I don't think 
> fragmentation matters within 0000::/8. I think people will commonly forget the 
> colon on the front of :1::/32, or mix up where the two contiguous colons are 
> e.g. they'll type ::1:/32.
>> 
> 
> as a /48 length prefix would satisfy the larger loopback prefix requirements.  
> However, within the parent 0000::/8 special purpose prefix, there are 
> approximately 16 million /32 prefixes, so a single /32 for the larger loopback 
> prefix is easily afforded.  A /32 larger loopback prefix will satisfy all 
> current and likely future uses of the loopback function.
>>> 
>>> 
>>  So you're saying that you can think of better uses for the 16 million 
> /32s within 0000::/8, such that just one can't be used for this purpose? 
> What are some of your better uses?
>> 
> 
> No, but I am saying I'm willing to bet that other better uses for the other 
> 65,535 /48s in 1::/32 are not at all unlikely to come along.
> 
>>> 
> within the larger loopback prefix is associated with one of the node's 
> interfaces, although not necessarily the same interface for all addresses.  This 
> means that the node acts as though all addresses within the larger loopback 
> prefix have been configured on one or more interfaces.  Applications will accept 
> packets destined to any of the larger loopback prefix addresses, unless the 
> application is bound to specific larger loopback addresses.  Typically the 
> addresses will be logically assigned to one or more virtual "loopback" 
> interfaces, which locally returns or loops outgoing packets back to the same 
> node that originated the packets.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>  This is specifying the address assignment and configuration scheme for the 
> proposed larger loopback prefix. You have misread and misunderstood this text.
>> 
> 
> No, I didn't. However, you claim "Consistent with…" and follow it 
> with a description which is not consistent.
> 
>>> 
> subsequent loopback interfaces, when initialised, should be assigned Smith      
>               Expires August 15, 2013                [Page 5] 
>>>  Internet-Draft        A Larger IPv6 Loopback Prefix        February 
> 2013 a larger loopback /64 prefix locally unique within the node.  All addresses 
> within the assigned /64 are logically assigned to the interface.  Additionally, 
> the ":1" address for the subnet should be configured on the loopback 
> interface, making it visible to a system operator or user.
>>> 
>>> 
> value to having that functionality and it is radically different from any 
> required functionality in IPv4 today. In IPv4, hosts which support multiple 
> loopbacks have no default address or range on the subsequent loopback 
> interfaces.
>>> 
>> 
>>  Right. The goal here is to take something useful in IPv4 that doesn't 
> exist in IPv6, and then to also see if there are opportunities to make further 
> improvements. This is not a literal copy of IPv4 functionality into IPv6. 
> Changes to fix limitations are also opportunities to make improvements.
>> 
> 
> My point is that the capability that exists in IPv4 today also exists in IPv6 
> already. The only difference is the pool of addresses you have to choose from 
> for that purpose. In IPv4, you have, in addition to the global unicast, 
> RFC-1918, and in some circumstances, link local addresses the normally unused 
> addresses within 127/8. In IPv6, you are limited to the ULA and GUA in addition 
> to ::1/128.
> 
>>> 
>>  I have justified it, in Abstract and the Introduction. You might not 
> believe there is a problem to solve, but that doesn't mean that other people 
> don't, and that they haven't experienced a problem. In addition to 
> myself, Erik Kline and Vijayrajan Ranganathan have encountered situations where 
> more IPv6 loopback addresses would be useful:
>> 
> 
> Your justification isn't. The problem statements you have presented so far 
> can be solved without requiring software modifications to every IPv6 stack.
> 
> configured loopback addresses.  It should also be possible for an operator to 
> configure further loopback addresses from within the assigned /64, or addresses 
> from other parts of the larger loopback prefix, including other /64s assigned to 
> other loopback interfaces. Other addresses within the assigned /64(s) would 
> continue to be logically assigned to the subsequent loopback interface. 
> Configuration of addresses is for operational visibility and convenience, and 
> does not change the behaviour of non-visible logically assigned addresses.
>>> 
>>> 
>>>  If you're going to do this, then I would argue that it 
> "must" be possible for an operator to remove…
>>> 
>> 
>>  ok. I've tried to avoid being too absolute in this area because 
> it's describing operator/system interface functionality, rather than things 
> a compliant implementation must do.
>> 
> 
> But you don't say that a compliant implementation must. As written, your 
> draft would allow a compliant implementation which did not allow operator 
> removal. I consider this highly undesirable.
> 
>> 
>>> 
>>  I'm curious as to what experience you have to be able to make that 
> judgement. Using Linux as an example IPv6 implementation, I know enough about 
> the Linux kernel networking code that I'm pretty sure it shouldn't be 
> too hard to make these changes.
>> 
> 
> I know that most hosts today do not behave well and most routers won't even 
> allow you to configure overlapping prefixes
> and addresses on multiple interfaces. Admittedly, some of that is due to the 
> fact that the desired behavior is not defined anywhere, which admittedly is 
> addressed to some extent in your draft. However, even with those definitions it 
> still strikes
>>>  This covers the first 6 pages (approximately half of the draft). 
> I'm not going to take the time to write up the problems in the rest of the 
> draft at this point because the above are, IMHO, more than sufficient reason to 
> oppose adoption.
>>> 
>>> 
>>>  Owen
>>> 
>>> 
>>>>>>  Nothing requires you to use random for this purpose. Use 
> fd00::/64 for all 
>>>>>>  anyone cares.
>>>>>> 
>>>>>> 
>>>>>  RFC4193 does. It's not a ULA if it doesn't, it's 
> been made a site-local. See RFC3879 for the problems with them and your 
> non-random ULA.
>>>>> 
>>>>> 
>>>>>>>  anything you want inside of that to provide a /64 for 
> your development 
>>>>>>>>  purpose.
>>>>>> 
>>>>>> 
>>>>>>>>  What's more cumbersome about picking something 
> (even fd00::/64, if 
>>>>>>>>  you want) 
>>>>>> 
>>>>>> 
>>>>>>>>  This proposal also takes the opportunity to 
> introduce IPv4-like 
>>>>>>>>>  handling of 
>>>>>> 
>>>>>>  loopback IPv6 packets so that future functions similar to 
> the use in 
>>>>>>>>  RFC4379 
>>>>>> 
>>>>>>  interface did just that, so I'm not sure what it is 
> that you feel 
>>>>>>>>  is 
>>>>>> 
>>>>>>  missing.
>>>>>>>> 
>>>>>>>> 
>>>>>>>  All addresses within 127/8 are valid and available on 
> the host, where as 
>>>>>>>  The authenticity of host '127.1.2.3 
> (127.1.2.3)' can't be 
>>>>>>>  established.
>>>>>> 
>>>>>> 
>>>>>>  From what I can see, this seems to depend on a pathology 
> not universally 
>>>>>>  available even in IPv4.
>>>>>> 
>>>>>> 
>>>>>>  I'm fine with it. If you're doing it more than 6 
> times, that's what 
>>>>>>  DNS is for.
>>>>>> 
>>>>>> 
>>>>>  That's an option, for applications that use DNS to resolve 
> addresses. There are applications that need to deal with addresses directly, 
>>>>>>>>>>  Primarily because we're asking people 
> to deploy this 
>>>>>>>>>>  protocol for 
>>>>>> 
>>>>>>>>>>  Put more simply, at some point we have to 
> stop tinkering with 
>>>>>>>>>>  the plane 
>>>>>> 
>>>>>> 
>>>>>>>> 
>>>>>>>>  while it's in the air.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>  implementations ("the plane") causing 
> them to fail 
>>>>>>>>  ("fall out of 
>>>>>> 
>>>>>>  loopback prefix would leverage many of the existing address 
> 
>>>>>>>>  configuration and 
>>>>>> 
>>>>>>  loopback related functions of existing IPv6 
> implementations. It is not 
>>>>>>>>  much more 
>>>>>> 
>>>>>>>>  The implication is that you are requesting to once 
> again obsolete all 
>>>>>>>>  existing 
>>>>>> 
>>>>>>  incorporated into software dependencies which would render 
> existing stacks 
>>>>>>  unexpectedly
>>>>>>  obsolete.
>>>>>> 
>>>>>> 
>>>>  IMHO, it's not all that useful and making it a stack 
> requirement would lead to one of two bad situations:
>>>> 
>>>>>  You seem to like doing things the hard way. My view is 
> computers should do things automatically for people so that people can get on 
> with more valuable things. Developers should be cutting code instead of setting 
> up development environments, or waiting for system administrators to set up the 
> development environment for them.
>>>>> 
>>>>> 
>>>>  Actually, I do not. However, I do not believe in using the entire 
> IP stack development community as a workforce to save me a little bit of typing 
> which, as near as I can tell is all that this proposal would accomplish.
>>>> 
>>>>  The functionality you seek is available using ULA. The issues you 
> cite with ULA would not apply to loopback usage. The functionality that you 
> attribute to RFC 1122 isn't (as near as I can tell) actually codified into 
> RFC 1122 (I don't see how requiring that an address range not appear outside 
> of a host requires that host to accept all packets to any address in said range, 
> which is what you are claiming).
>>>> 
>>>> 
>>>>>  I don't get this. 1::/32 is not currently used for 
> anything, so using it is not going to make it incompatible with anything. Using 
> other prefixes for purposes that they weren't designed for, such as a ULA as 
> a loopback, has far greater risk of creating incompatibility. 
>>>>> 
>>>>>>>>  justify such a decision and IMHO, at this point, 
> just to make it 
>>>>>>>>  "less 
>>>>>> 
>>>>>  You don't seem to be placing any value convenience. Does 
> your car have an automatic transmission? Do you have a dishwasher? Do you go to 
> restaurants? All of those things only exist because humans place value on the 
> convenience of not manually changing gears, not manually washing dishes, and not 
> cooking at home when we could. Why have to do something manually when a computer 
> could do it automatically for you?
>>>>> 
>>>>> 
> traditional automatic transmission, my car has an ECVT transmission. If I were 
> buying a car, I would actually prefer a manual transmission because I prefer the 
> greater control flexibility and shifting precision afforded by a manual 
> transmission.
>>>> 
> available without involving the entire body of protocol developers and the IETF 
> in the process.
>>>> 
>>>>  Owen
>>>> 
>>>> 
>>>>  Owen
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  Regards,
>>>>>>>>>  Mark.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  Doug
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>  Perhaps I'm not very bright, but is 
> there any 
>>>>>>>>>>>>  reason ULA 
>>>>>> 
>>>>>>  couldn't be
>>>>>>>>>> 
>>>>>>>>        However this prefix would need to be manually 
> 
>>>>>>>>>>>  generated and
>>>>>> 
>>>>>>>>>>>>>  Here is a new version of my 
> IPv6 larger loopback 
>>>>>>>>>>>>>  prefix 
>>>>>> 
>>>>>>  draft.
>>>>>>>> 
>>>>>>>>>>>>>  o  default address selection 
> precedence and label 
>>>>>>>>>>>>>  values
>>>>>> 
>>>>>>>>>>>>>  My thanks to Bill Atwood, Matts 
> Kallioniemi and 
>>>>>>>>>>>>>  Tina Tsou 
>>>>>> 
>>>>>>  for their
>>>>>>>> 
>>>>>>>>>>>>>  Further review and comments 
> would be most 
>>>>>>>>>>>>>  appreciated.
>>>>>> 
>>>>>> 
>>>>>>>>>>>>>  Thanks,
>>>>>>>>>>>>>  Mark.
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 13 Feb 2013 22:39:32 -0800

> So you've resorted to insults. I ignore people who resort to insults, because they've clearly run out of actual points of argument, and won't accept that other people have and can have different on…
This branch of the thread can stop now.