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

From: Mark Smith <[email-masked]>
Date: Wed, 20 Feb 2013 11:27:56 -0800 (PST)

Hi,

Here is a new version of my larger IPv6 loopback prefix draft. Changes since the last version are relatively minor:

   o  usability references (DOET and EASY-NUMBERS)
 
   o  minor clarifications
 
   o  grammar corrections

Further review welcome and appreciated.

Regards,
Mark.

----- Forwarded Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> 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:     draft-smith-v6ops-larger-ipv6-loopback-prefix
> Revision:     04
> Title:         A Larger Loopback Prefix for IPv6
> Creation date:     2013-02-20
> Group:         Individual Submission
> Number of pages: 12
> URL:            
> http://www.ietf.org/internet-drafts/draft-smith-v6ops-larger-ipv6-loopback-prefix-04.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-04
> Diff:            
> http://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-larger-ipv6-loopback-prefix-04
> 
> 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 commonly 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 processing rules
>    for this new larger loopback prefix also allow sending or forwarding
>    of packets containing these addresses beyond the originating router
>    under certain circumstances.
> 
>                                                                                 
>   
> 
> 
> The IETF Secretariat
>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Feb 2013 11:37:43 -0800

This version has done nothing to address my previously stated objections and concerns.

Owen

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

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

---

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

Hi Owen,

----- Original Message -----
> From: Owen DeLong <[email-masked]>
> To: Mark Smith <[email-masked]>
> Cc: v6ops v6ops WG <[email-masked]>
> Sent: Thursday, 21 February 2013 6:37 AM
> Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt
> 
>T his version has done nothing to address my previously stated objections and 
> concerns.
> 

I didn't intend it to.

You seem to believe that the best solution to this problem would be to reserve the all-zeros Global ID of the ULA prefix. I disagree with that for quite 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 dependent on a new prefix being allocated for this purpose, rather than changing the purpose of one of the prefixes within the ULA prefix. I consider the number of changes I'd have to make my draft use a ULA prefix significant, such 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 spend significantly more (if you compare draft 00 with 01, you can see that was an almost complete rewrite).

So if you think using prefix from within the ULA prefix is the better solution, then I think it would be better if you wrote up an ID to propose it and provide the corresponding details.

Regards,
Mark.

>>  Here is a new version of my larger IPv6 loopback prefix draft. Changes 
> since the last version are relatively minor:
>> 
>>>  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

---

From: james woodyatt <[email-masked]>
Date: Wed, 20 Feb 2013 12:34:14 -0800

On Feb 20, 2013, at 11:27 , Mark Smith <[email-masked]> wrote:
> 
> Here is a new version of my larger IPv6 loopback prefix draft. [...]

I see no need for a shorter prefix for a node-local addressing scope.  I think using fe80::/10 on loopback interfaces is sufficient for this purpose.  Consider the output of ifconfig lo0 on the OS X 10.8 machine I'm using to write this message:

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

There are already two interface addresses attached to the single loopback interface on my system, and room in the number space for another 2^118 - 1 addresses, which is certainly well beyond the capacity of my host operating system to field. Because the interface is loopback, the reachability of fe80::1%lo0 is constrained to node-local peers. Additional loopback interfaces would entail additional addresses with a different scope identifier.

Worth noting, IPv6 Scoped Address Architecture [RFC 4007] makes several references to a loopback interface. It may not be formally required by the standard, but it seems to be a common feature, and it would make more sense to formalize existing practice than to carve out a whole new address allocation for node-local scopes.

Section 2.5.3 of IP Version 6 Addressing Architecture [RFC 4291] also mentions a conceptual loopback interface.  It's worth looking at how this section has evolved in the progression from RFC 1884, the first published IPv6 Addressing Architecture document.

[RFC 1884]
>> 
>> 2.4.3 The Loopback Address
>> 
>>    The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
>>    It may be used by a node to send an IPv6 datagram to itself.  It may
>>    never be assigned to any interface.
>> 
>>    The loopback address must not be used as the source address in IPv6
>>    datagrams that are sent outside of a single node.  An IPv6 datagram
>>    with a destination address of loopback must never be sent outside of
>>    a single node.

Notice that the original concept was an address that was not assigned to any interface.  No mention of a loopback interface is present.  This was found to be too limiting, and the restriction was modified in RFC 2373 to apply only to "physical" interfaces, and this language has been carried forward to RFC 4291, the current standard.

[RFC 4291]

>> 2.5.3 The Loopback Address
>> 
>>    The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
>>    It may be used by a node to send an IPv6 packet to itself.  It may
>>    never be assigned to any physical interface.   It is treated as
>>    having link-local scope, and may be thought of as the link-local
>>    unicast address of a virtual interface (typically called "the
>>    loopback interface") to an imaginary link that goes nowhere.
>> 
>>    The loopback address must not be used as the source address in IPv6
>>    packets that are sent outside of a single node.  An IPv6 packet with
>>    a destination address of loopback must never be sent outside of a
>>    single node and must never be forwarded by an IPv6 router.  A packet
>>    received on an interface with destination address of loopback must be
>>    dropped.

I don't see how this new proposed draft improves on existing operational practice.

--
james woodyatt <[email-masked]>
core os networking

---

From: Philipp Kern <[email-masked]>
Date: Wed, 20 Feb 2013 23:01:06 +0100

On Wed, Feb 20, 2013 at 12:34:14PM -0800, james woodyatt wrote:
> Because the interface is loopback, the reachability of
> fe80::1%lo0 is constrained to node-local peers. Additional loopback
> interfaces would entail additional addresses with a different scope
> identifier.

Was the interface specification standarized already? AFAIK applications need to
implement manual parsing to support them instead of just passing an address to
the OS API.

Kind regards
Philipp Kern

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2013 12:00:30 +1100

In message <[email-masked]>, Owen DeLong write
> This version has done nothing to address my previously stated objections and 

Agreed.

The entire premise of this draft is based on "we did it this way with IPv4
so we need to do it this way with IPv6".  IPv6 is very different.

* From the start IPv6 has has link local addresses.  This includes the
  loopback interface.

* When 127/0 was reserved there weren't RFC 1918 address ranges.  There
  weren't IPv4 link local address ranges.

* Today we have ULA address.  If you are worried about collisions
  we can use a centrally assigned unique local address. fc00::/48
  is easy enough to remember and type, has never been assigned and
  is is a existing reserved block of tainted addresses.  fc00::/48
  could be the first assignment in that range.

B.T.W.  We do testing of our products over IPv6 loopback interfaces
today and have done for years without the need for this draft.  We
choose a ULA prefix to do this.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2013 12:25:40 +1100

In message <[email-masked]>, Mark S
mith writes:
> > 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

> > =
> > =
> >> =
> >>  Here is a new version of my larger IPv6 loopback prefix draft. Changes =
> 
> >> =
> >> =A0 =A0 o=A0 usability references (DOET and EASY-NUMBERS)
> >> =A0 =
> 
> >> =A0 =A0 o=A0 minor clarifications
> >> =A0 =
> 
> >> =A0 =A0 o=A0 grammar corrections
> >> =
> 
> >> =
> >> =
> >> =
> >>>  From: "[email-masked]" =
> 
> > <[email-masked]>
> >>>  Cc: =
> >>>  Subject: New Version Notification for =
> 
> >>> =
> >>> =
> >>>  A new version of I-D, =
> >>> =
> >>>  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
> >>> =
> 
> > =

---

From: james woodyatt <[email-masked]>
Date: Wed, 20 Feb 2013 19:02:29 -0800

> implement manual parsing to support them instead of just passing an address to

I guess that you're asking about this:

  Representing IPv6 Zone Identifiers in Address Literals
  and Uniform Resource Identifiers [I-D.carpenter-6man-uri-zoneid]

  <http://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/>

Looks like it is currently in the AUTH48 state.

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Feb 2013 19:07:28 -0800 (PST)

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 <[email-masked]>
> Cc: Owen DeLong <[email-masked]>; v6ops v6ops WG <[email-masked]>
> Sent: Thursday, 21 February 2013 12:25 PM
>>  >>>  Filename:=A0 =A0  
> draft-smith-v6ops-larger-ipv6-loopback-prefix
>>  >>>  Revision:=A0 =A0  04

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2013 16:29:18 +1100

In message <[email-masked]>, Mark S
> 1. it has been easy to remember

so is fc00::/48

> 2. it has been (pretty) easy to type

so is fc00::/48
 
> 4. there has been a well known 127.0.0.1/8 automatically configured 
> address, visible to the user and assisting their memory

So is ::1 if you have IPv6 enabled.  Note 127.0.0.1/8 may not be
available on some nodes as they remove IPv4 support.

> 5. it has uniquely identified the loopback interface

As would fc00::/48 if it was assigned for that purpose.

> 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

Having addresses other than 127.0.0.1 usable in any form by default
is implementation dependent.

> 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

And one can achieve that with a ULA address and a firewall if you want to. 

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

Well you can't meet 3 as it was not backed into the original design
 
> 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.
> 

Nothing can meet 3 unless you have a time machine.

fd00::/64 or fc00::/64 will meet 4 and that is just a matter of
familiarity with whatever address range is choosen.  There was
nothing special about 10/8 or 172.16/12 or 192.168/16 apart from
10/8 being available.  Most people involved with configuring machines
can identify these ranges.

fc00::/64 can meet 5 as can any prefix that gets reserved.

6 is a implementation detail that is not required for RFC conformance
and is not implemented on many platforms.

Mark

---

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

----- Original Message -----
> Sent: Thursday, 21 February 2013 4:29 PM

sigh. RFC4193:

"3.2.  Global ID
The allocation of Global IDs is pseudo-random [RANDOM].  They MUST NOT be assigned sequentially or with well-known numbers."

Given your name is on the top of RFC6303, I'd have thought you'd agree it is important to follow what is in them.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2013 18:03:14 +1100

In message <[email-masked]>, Mark S
mith writes:
> > Subject: Re: [v6ops] Fw: New Version Notification for 
> > In message 
> <[email-masked]>, 
> > Mark S
> > mith writes:
> >>  Ok.
> >> 
> The allocation of Global IDs is pseudo-random [RANDOM].  They MUST NOT be 
> assigned sequentially or with well-known numbers."
> 

Reserving fc00::/48 for loopback purposes would have no impact on
RFC6303 you will note the 127.in-addr.arpa is one of the listed
prefixes. 

And if you were to read the rest of the section you quotes you will
see that fc00::/48 is still reserved.

   "This document defines a specific local method to allocate Global IDs,
   indicated by setting the L bit to 1.  Another method, indicated by
   clearing the L bit, may be defined later."

fc00::/48 is still fair game for this purpose.  ULA locally or
centrally assigned are all potentially ambigious.  Neither are
expected to be routed over the Internet.  A reserved loopback prefix
by definion is always ambigious.  fc00::/48 would not be ambigous
within the context of a node.  fc00::/48 has the advantage that
leaked packets / routes are already subject to filtering restrictions.

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Feb 2013 16:07:33 +0900

On Thu, Feb 21, 2013 at 4:03 PM, Mark Andrews <[email-masked]> wrote:

> centrally assigned are all potentially ambigious.

If that were so, ULA addresses would not be specified as having global
scope.

Even if we do assign fc00::/48 as a loopback prefix, it will be considered
to have global scope for all implementations that have not yet been
updated. That seems undesirable.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Feb 2013 23:06:08 -0800

> Given your name is on the top of RFC6303, I'd have thought you'd agree it is important to follow what is in them.

RFC4193 does not apply to fc00::/48. It only applies to fd00::8. fc00::/8 currently has no RFCs specifying it other than the part of 4193 that says it is intended for globally unique registered ULA. However, the companion RFC that provided for that failed to gain consensus, so fc00::/8 is actually in limbo. As far as I'm concerned, this would be a perfectly fine use of fc00::/48 as the first registered ULA.

Further, when considering RFCs in a particular use case, I think it is important to apply the context of WHY the RFC says what it says. In this case, there is no downside to (mis)using ULA in this way on a local basis because you can choose a non-conflicting ULA prefix pretty easily. Afterall, all that is required is that it not conflict with ULA in use by any of the machines that your test subject will be sending packets to.

Blind adherence to the RFCs without context is almost as silly as blind ignorance of them.

Owen

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Feb 2013 11:33:14 -0800

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

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

Have you tried it?  [Insert "IT WORKS ON MY MACHINE" LOL-cat graphic here.]

> Special link-local behaviour on the loopback interface isn't specified as far as I know [...]

As far as you know.  Look, if you think what's already there in RFC 4007 and RFC 4291 isn't clear enough, then let's see a draft to clean that up.  I'm prepared to support a reasonable effort to do that.

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

Really?  Having to use a zone identifier on the address literal is enough to make it too hard to type and remember?  I get that <http://127.0.0.2/> looks a little less messy than <http://[fe80::2%25lo0]/>, but it's really not *that* much worse, is it?  Outside the URI syntax, it's even easier.

I need a T-shirt that says:

            THERE'S NO PLACE LIKE ::1
  
   (except fe80::1%lo0, which is just like it)

---

From: Mark Smith <[email-masked]>
Date: Thu, 21 Feb 2013 12:23:49 -0800 (PST)

Just so everybody knows, I've given up on this, as obviously it is not going to achieve consensus, and I've spent as much of my own time on it as I'm going to.

----- Original Message -----
> From: Mark Smith <[email-masked]>
> To: v6ops v6ops WG <[email-masked]>
> Cc: 
> Sent: Thursday, 21 February 2013 6:27 AM
> Subject: Fw: New Version Notification for draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt
> 
> Hi,
>