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

[Mark Smith <[e-mail]>]

Ok.

Lets look at the experience I and others have had using 127/8

1. it has been easy to remember

2. it has been (pretty) easy to type

3. it has always been there

4. there has been a well known 127.0.0.1/8 automatically configured address, visible to the user and assisting their memory

5. it has uniquely identified the loopback interface

6. common hosts (windows/Linux and probably other unicies (from distant memory, HP-UX probably)) all addresses within 127/8 have also been conceptually assigned (e.g. http:://127.1.2.3:80/ just worked, as did http://127.8.7.6:80, without configuration). IOW, there were plenty of automatically configured addresses, and no additional effort required to enable them

7. traffic towards all addresses within 127/8 never leaked from the host, because it was configured to loop traffic by default at system initialisation

::1/128 provides IPv6 equivalents of 1,2,3,4,5 and 7. It does not provide multiple addresses (6). A larger version of ::/128, that satisfies 1 through 7 is the motive for this draft.

Other prefixes suggested (and ones I considered and tried using before I started writing this draft) would need specification updates to automatically behave as above. Otherwise they need manual configuration, possibly in addition to violation of their intended use and form.

For example, fe80::1/10 might be automatically configured on Mac OS X on the loopback interface, but can you use fe80::2, fe80::3, fe80::4567:1234 and have them all automatically work? Special link-local behaviour on the loopback interface isn't specified as far as I know, so it probably won't So it doesn't satisfy 3 and 5, and since link-local doesn't have anything to distinguish the link local prefix on loopback from eth0, you also have to specify an interface, so it also fails 2.

A non-unique ULA of fd00::/64 fails 3, 4, 5 and 6.






----- Original Message -----
> From: Mark Andrews <[e-mail]>
> To: Mark Smith <[e-mail]>
> Cc: Owen DeLong <[e-mail]>; v6ops v6ops WG <[e-mail]>
> Sent: Thursday, 21 February 2013 12:25 PM
> Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt
> 
> 
> In message <[e-mail]>, 
> Mark S
> mith writes:
>>  Hi Owen,
>> 
>> 
>>  ----- Original Message -----
>>  > From: Owen DeLong <[e-mail]>
>>  > To: Mark Smith <[e-mail]>
>>  > Cc: v6ops v6ops WG <[e-mail]>
>>  > Sent: Thursday, 21 February 2013 6:37 AM
>>  > Subject: Re: [v6ops] Fw: New Version Notification for 
> draft-smith-v6ops-l=
>>  arger-ipv6-loopback-prefix-04.txt
>>  > =
>> 
>>  >T his version has done nothing to address my previously stated 
> objections =
>>  and =
>> 
>>  > concerns.
>>  >=A0
>> 
>>  I didn't intend it to.
>> 
>>  You seem to believe that the best solution to this problem would be to 
> rese=
>>  rve the all-zeros Global ID of the ULA prefix. I disagree with that for 
> qui=
>>  te number of reasons (with another one being that the "Unique" in 
> ULA would=
>>   now be false). Many of the things I have proposed are fundamentally 
> depend=
>>  ent on a new prefix being allocated for this purpose, rather than changing 
> =
>>  the purpose of one of the prefixes within the ULA prefix.=A0I consider the 
> =
>>  number of changes I'd have to make my draft use a ULA prefix 
> significant, s=
>>  uch that I'd end up pretty much writing your proposal, rather than 
> mine. I'=
>>  ve spent quite a lot of my own time and effort on this, I don't want to 
> spe=
>>  nd significantly more (if you compare draft 00 with 01, you can see that 
> wa=
>>  s an almost complete rewrite).
> 
> Part of presenting a proposal is demonstrating why existing methods
> do not work.  There are a number plain falsehoods in your draft.
> 
> "Multiple IPv6 loopback addresses are not available to bind application
> instances to when using the same port on the same host." is a
> falsehood.
> 
> There is *nothing* in the IPv6 architecture to prevent the operator
> of the machine configuring additional loopback addresses.  In fact
> multiple loopback addresses are rarely used and whenever they are
> used some level of configuration is required.
> 
>>  So if you think using prefix from within the ULA prefix is the better 
> solut=
>>  ion, then I think it would be better if you wrote up an ID to propose it 
> an=
>>  d provide the corresponding details.
> 
> No. It is your job to demonstrate why existing mechanisms are not
> sufficient and the first step is to present a honest eveluation of
> why they are not so.  I don't believe you were being intentionally
> dishonest but there is a lack of rigour in your analysis of the
> currently available mechanisms.
> 
> Mark
> 
>>  Regards,
>>  Mark.
>>  > =
>> 
>>  > On Feb 20, 2013, at 11:27 , Mark Smith 
> <[e-mail]> wrote:
>>  > =
>> 
>>  >>  Hi,
>>  >> =
>> 
>>  >>  Here is a new version of my larger IPv6 loopback prefix draft. 
> Changes =
>> 
>>  > since the last version are relatively minor:
>>  >> =
>> 
>>  >> =A0 =A0 o=A0 usability references (DOET and EASY-NUMBERS)
>>  >> =A0 =
>> 
>>  >> =A0 =A0 o=A0 minor clarifications
>>  >> =A0 =
>> 
>>  >> =A0 =A0 o=A0 grammar corrections
>>  >> =
>> 
>>  >>  Further review welcome and appreciated.
>>  >> =
>> 
>>  >>  Regards,
>>  >>  Mark.
>>  >> =
>> 
>>  >> =
>> 
>>  >>  ----- Forwarded Message -----
>>  >>>  From: "[e-mail]" =
>> 
>>  > <[e-mail]>
>>  >>>  To: [e-mail]
>>  >>>  Cc: =
>> 
>>  >>>  Sent: Thursday, 21 February 2013 6:17 AM
>>  >>>  Subject: New Version Notification for =
>> 
>>  > draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt
>>  >>> =
>> 
>>  >>> =
>> 
>>  >>>  A new version of I-D, =
>> 
>>  > draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt
>>  >>>  has been successfully submitted by Mark Smith and posted to 
> the
>>  >>>  IETF repository.
>>  >>> =
>> 
>>  >>>  Filename:=A0 =A0  
> draft-smith-v6ops-larger-ipv6-loopback-prefix
>>  >>>  Revision:=A0 =A0  04
>>  >>>  Title:=A0 =A0 =A0 =A0  A Larger Loopback Prefix for IPv6
>>  >>>  Creation date:=A0 =A0  2013-02-20
>>  >>>  Group:=A0 =A0 =A0 =A0  Individual Submission
>>  >>>  Number of pages: 12
>>  >>>  URL:=A0 =A0 =A0 =A0 =A0 =A0 =
>> 
>>  >>> =
>> 
>>  > 
> http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopbac=
>>  k-prefix-04.txt
>>  >>>  Status:=A0 =A0 =A0 =A0 =A0 =
>> 
>>  >>> =
>> 
>>  > 
> http://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-pr=
>>  efix
>>  >>>  Htmlized:=A0 =A0 =A0 =A0 =
>> 
>>  >>> =
>> 
>>  > 
> http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-=
>>  04
>>  >>>  Diff:=A0 =A0 =A0 =A0 =A0 =A0 =
>> 
>>  >>> =
>> 
>>  > 
> http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-v6ops-larger-ipv6-loopback=
>>  -prefix-04
>>  >>> =
>> 
>>  >>>  Abstract:
>>  >>> =A0 =A0 During the development and testing of a network 
> application, it=
>>   can
>>  >>> =A0 =A0 be useful to run multiple instances of the application 
> using th=
>>  e =
>> 
>>  > same
>>  >>> =A0 =A0 transport layer protocol port on the same development 
> host, whi=
>>  le
>>  >>> =A0 =A0 also having network access to the application 
> instances limited=
>>   to
>>  >>> =A0 =A0 the local host.=A0 Under IPv4, this has commonly been 
> possible =
>>  by =
>> 
>>  > using
>>  >>> =A0 =A0 different loopback addresses within 127/8.=A0 It is 
> not possibl=
>>  e under
>>  >>> =A0 =A0 IPv6, as the loopback prefix of ::1/128 only provides 
> a single
>>  >>> =A0 =A0 loopback address.=A0 This memo proposes a new larger 
> loopback p=
>>  refix
>>  >>> =A0 =A0 that will provide many IPv6 loopback addresses.=A0 The 
> processi=
>>  ng =
>> 
>>  > rules
>>  >>> =A0 =A0 for this new larger loopback prefix also allow sending 
> or forwa=
>>  rding
>>  >>> =A0 =A0 of packets containing these addresses beyond the 
> originating ro=
>>  uter
>>  >>> =A0 =A0 under certain circumstances.
>>  >>> =
>> 
>>  >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 
> =A0 =A0 =A0=
>>   =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
>> 
>>  > =A0 =A0 =A0 =A0 =
>> 
>>  >>> =A0 =
>> 
>>  >>> =
>> 
>>  >>> =
>> 
>>  >>>  The IETF Secretariat
>>  >>> =
>> 
>>  >>  _______________________________________________
>>  >>  v6ops mailing list
>>  >>  [e-mail]
>>  >>  https://www.ietf.org/mailman/listinfo/v6ops
>>  > =
>> 
>>  _______________________________________________
>>  v6ops mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/v6ops
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>