Subject: [v6ops] Should we use "unnumbered" in IPv6?

From: Philip Matthews <[email-masked]>
Date: Tue, 10 Mar 2015 10:52:10 -0400

Just want to get some direct feedback from the WG on the use of the terms "unnumbered interface" and "unnumbered link" in IPv6.

Mark Smith, in some comments on the Design Choices draft , has said that he prefers the terms "interface with only link-local address" or "link with only link-local addresses" instead.   See the thread with title "I-D Action: draft-ietf-v6ops-design-choices-04.txt".

What does the WG think?  Should we use the "unnumbered" terms, or should we use just the "... with only link-local address" terms?  Is it acceptable to mix the two sets of terms?

Philip

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 10 Mar 2015 15:39:44 +0000

I would use "unnumbered" which is then one common term with ipv4 and ipv6 used for interfaces on routers from multiple vendors. 

Thanks,

Hemant

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Philip Matthews
Sent: Tuesday, March 10, 2015 10:52 AM
To: v6ops list
Subject: [v6ops] Should we use "unnumbered" in IPv6?

Philip

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 10 Mar 2015 16:12:09 +0000

> Just want to get some direct feedback from the WG on the use of the terms
> "unnumbered interface" and "unnumbered link" in IPv6.
> 
> Mark Smith, in some comments on the Design Choices draft , has said that he
> prefers the terms "interface with only link-local address" or "link with only
> link-local addresses" instead.   See the thread with title "I-D Action: draft-ietf-
> v6ops-design-choices-04.txt".
> 
> What does the WG think?  Should we use the "unnumbered" terms, or
> should we use just the "... with only link-local address" terms?  Is it
> acceptable to mix the two sets of terms?

My experience with "unnumbered" interfaces is exclusively in the access network, specifically on the WAN interface of a CE (customer edge) router.

In that context (to provide a point of reference as to the term's use elsewhere in the industry, just FYI), BBF TR-177 (http://www.broadband-forum.org/technical/download/TR-177.pdf ) defines the following terms:
Numbered WAN model: The WAN interface of the RG has its own IPv6 GUA.
Unnumbered WAN model: The WAN interface of the RG does not have its own IPv6 GUA.

Since the CE router (aka RG) has multiple interfaces (and not just the WAN), this does not prevent the CE router from having a GUA assigned to one of its other interfaces (which it takes from its delegated prefix -- see RFC 7084, WAA-7). This provides the CE router with a globally ping-able address, which effectively handles some of the negatives of these interfaces.

I'm also familiar with the use of the "unnumbered" term related to CE router WAN interfaces intended to handle receiving IPv4 multicast (IPTV) traffic. 0.0.0.0 is often used for that interface. But since the CE router also has a "normal" WAN interface (the WAN "link" has separate VLANs for multicast and regular Internet traffic), this doesn't result in any of the described problems.

Out of curiosity: CE routers don't seem to be a primary target of this draft, but are they excluded?

To get back to the question of whether to use "unnumbered" in this draft: "Unnumbered" is only used 5 times in the draft. I think that its common use in the industry makes it ok, but I also think "unnumbered interface"  could be easily replaced with "interface without a link-local address". The first instance ' a.  Use only link-local addresses ("unnumbered") ' should stay to acknowledge the fact that this word is widely used in this context. I have to admit to not completely understanding what an "unnumbered link" is (in the last instance of "unnumbered"), given that it's possible for a link to have multiple interfaces (from the draft: "separate interfaces" can exist as "two VLANs on the same link"), some of which may be numbered and some of which may be unnumbered (based on my CE router IPTV experiences). Does "unnumbered link" mean a link where all of its interfaces are unnumbered (have no link-local address)? Anyway, I'm ambivalent about making the change. I think it's fine either way (as long as the first instance of "unnumbered" stays).

Barbara

---

From: Gert Doering <[email-masked]>
Date: Tue, 10 Mar 2015 17:15:21 +0100

Hi,

> What does the WG think?  Should we use the "unnumbered" terms, or should we use just the "... with only link-local address" terms?  Is it acceptable to mix the two sets of terms?

I'm fine with "unnumbered", but then, I have a router background with
the config option "ip[v6] unnumbered <otherinterface>" being frequently 
used...  and it's less words, so, preferred :-)

OTOH I wouldn't mind a footnote on the first use of "unnumbered" explaining
that "for the purpose of this document, this identifies an interface or link
that only has link-local addresses".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Alejandro Acosta <[email-masked]>
Date: Tue, 10 Mar 2015 11:50:17 -0430

Hello,
  I feel comfortable with the term unnumbered. It's easier to read. Of
course in the document should be expressed that such interfaces/links
have only-link-local addresses.

Alejandro,

---

From: [email-masked]
Date: Tue, 10 Mar 2015 17:24:50 +0100 (CET)

> I would use "unnumbered" which is then one common term with ipv4 and ipv6 used for interfaces on routers from multiple vendors. 

Agreed.

Steinar Haug, AS 2116

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 10 Mar 2015 19:41:49 +0000

> On Mar 10, 2015, at 7:52 AM, Philip Matthews <[email-masked]> wrote:
> 

</chair>

From my perspective, Mark is correct.

IPv4 actually has unnumbered links - links with no address. On such links, when one sends a packet, one uses the address found on a different interface, and the only system that can send to you on the unnumbered link using the borrowed address is one that is sending to the *interface* as opposed to the *address* - a neighboring router.

In IPv6, one actually does have an address on every link (if only the link-local address), and as a result never “borrows” an address from another interface.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Mar 2015 09:29:27 +1300

> In IPv6, one actually does have an address on every link (if only the link-local address), and as a result never “borrows” an address from another interface.

Well, hang on. There is the infamous case of traceroutes including link-local
addresses, and the correct fix is to borrow another address from the box
to provide a global address.

But I agree that the terminology is slippery (as is the term "loopback interface").

   Brian

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 10 Mar 2015 21:15:31 +0000

Philip

In the legacy world of IPv4, unnumbered actually means using a global IPv4
address 'stolen' from another interface.

In the current world of IPv6, every interface has at least a link-local
address which can be used for IGP and other purposes (see RFC 7404) which
is NOT equivalent (IMHO) to 'unnumbered interface'

So, I am afraid that you should use another working (albeit cumbersome)

-éric

On 10/03/15 15:52, "Philip Matthews" <[email-masked]> wrote:

>Mark Smith, in some comments on the Design Choices draft , has said that
>he prefers the terms "interface with only link-local address" or "link
>with only link-local addresses" instead.   See the thread with title "I-D
>Action: draft-ietf-v6ops-design-choices-04.txt".
>
>What does the WG think?  Should we use the "unnumbered" terms, or should
>we use just the "... with only link-local address" terms?  Is it

---

From: joel jaeggli <[email-masked]>
Date: Tue, 10 Mar 2015 14:53:42 -0700

given that we have the link local only draft floating around it seems
like we have discussed this some in the v6 context.

there are certain things you need or should use a globally signficant ip
for (responding to traceroute for example). and some thing link local is
more than sufficient for (forming an adjacency)

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Mar 2015 00:15:52 +0000 (UTC)

People probably haven't seen the text I wrote regarding why I don't think "unnumbered" should be used, so here it is. Also, people in this thread putting "unnumbered" in quotes also indicates that it is an inaccurate term. If term was a good and accurate one to use, then it wouldn't need quotes.

/ The concern I have with continuing to use an incorrect term, even though it might be fairly commonly used, is that the longer it is used, the longer it can cause confusion or error, and the longer it encourages the use of the inaccurate term.

/ Somebody who knows very little about IPv6 (which might be a reasonable portion of the audience of your document) would assume an 'unnumbered' link would have no IPv6 addressing present at all on any of the attached interfaces, because that is the case with IPv4. That misunderstanding can have security implications, as unnumbered IPv4 links can't by default support IPv4 applications if hosts are attached to the IPv4 unnumbered link, where as 'unnumbered' IPv6 links can (because they're not actually unnumbered).

/ Another point of confusion would be that in IPv4, unnumbered links are usually only serial point-to-point links between routers, meaning that hosts can't physically be attached to the link, where as any type of link can be an IPv6 "unnumbered" link, so hosts may be physically attached to the link if the link-layer is multi-access.

/ These subtle yet significant differences are the ones that, if hidden by incorrect terminology, create opportunities for security or operational problems. In my experience avoiding those issues is far cheaper and easier than cleaning up after they've occurred.

/ I think in your document it would be better to use the term 'link-local only' throughout the document, and just acknowledge once early in the document that it has been also described as 'unnumbered' as it is somewhat similar to the IPv4 concept of unnumbered link, but certainly isn't the same.

----- Original Message -----
From: Philip Matthews <[email-masked]>
To: v6ops list <[email-masked]>
Cc: Victor Kuarsingh <[email-masked]>; Mark ZZZ Smith <[email-masked]>
Sent: Wednesday, 11 March 2015, 1:52
Subject: Should we use "unnumbered" in IPv6?

Philip

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 11 Mar 2015 00:22:56 +0000 (UTC)

I'll also point out that I completely understand why it is occurred. It is easier for people to learn things based on things that are similar to what they know, and link-local only IPv6 links are conceptually quite similar to IPv4 unnumbered links. 

Of course there are also differences, and when something is different, we give it a different name to distinguish it (or a qualifier, however "link-local numbered, unnumbered links" is pretty clumsy (!))

----- Original Message -----
From: Philip Matthews <[email-masked]>
To: v6ops list <[email-masked]>
Cc: Victor Kuarsingh <[email-masked]>; Mark ZZZ Smith <[email-masked]>
Sent: Wednesday, 11 March 2015, 1:52
Subject: Should we use "unnumbered" in IPv6?

Philip

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Wed, 11 Mar 2015 00:42:54 -0700

There is a bunch of stuff in IPv6 that is different from IPv4
operations.  It is a different protocol, after all.  Lots of paradigms
are different, most especially that of addressing.  Even though I gather
there is substantial support for calling those links "unnumbered" on the
basis of familiarity, Mark is completely right in saying that this is
the kind of thing that causes confusion and oversight later on, and
would create something unintuitive to future network engineers in a
world where IPv6 is dominant.  The difference whereby no IPv4 address is
borrowed (and instead a link-local address is used) is sufficient to
make this a very different configuration.

I put forth the term "locally-numbered" as a succinct and apropos
alternative.

--Falcon Darkstar Momot
--Shadytel

---

From: Erik Kline <[email-masked]>
Date: Wed, 11 Mar 2015 16:51:31 +0900

> I put forth the term "locally-numbered" as a succinct and apropos

I was thinking about that as well, but dropped it on the assumption
that if the context were mistaken in conversation to be IPv4 (or we
wanted a common term for both) that locally-numbered might be
interpreted as "has RFC1918 addresses".

(Sorry, I really don't want to take us down the road of the "hextet"
discussion. :-)

---

From: Owen DeLong <[email-masked]>
Date: Wed, 11 Mar 2015 00:55:00 -0700

I see no benefit and many drawbacks to link-local numbered and unnumbered interfaces.

Among them:

Link Local numbered interfaces are unlikely to be unambiguous when they appear in traceroutes.
They are virtually guaranteed not to makes sense or provide useful information outside of your administrative domain.

Unnumbered interfaces provide information only on which router received a packet, but not which interface. This can often be confusing, misleading, or outright useless when troubleshooting.

In IPv4, address scarcity might, in some circumstances create sufficient incentive to use such things.

In IPv6, there is no address scarcity, so I can’t see any upside whatsoever to either of these constructs.

Owen

> On Mar 11, 2015, at 00:42 , Falcon Darkstar Momot <[email-masked]> wrote:
>

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Wed, 11 Mar 2015 01:47:24 -0700

> (Sorry, I really don't want to take us down the road of the "hextet"

Potentially, but I believe the common terminology there is "privately
numbered" or just "private" (which is its own horror with respect to the
security confusion it creates, especially in conjunction with the
nat-is-a-firewall mentality, but I digress).  Incidentally, it is common
to use RFC1918 addresses in IPv4 routers, leading to the abomination of
RFC1918 addresses returned in traceroutes.  You just can't win with
private-use space.

--Falcon Darkstar Momot
--Shadytel

---

From: Gert Doering <[email-masked]>
Date: Wed, 11 Mar 2015 11:14:19 +0100

Hi,

> (Sorry, I really don't want to take us down the road of the "hextet"

We're already on the way...  expecting a long linguistic treaty next.

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 11 Mar 2015 11:17:26 +0100 (CET)

> What does the WG think?  Should we use the "unnumbered" terms, or should we use just the "... with only link-local address" terms?  Is it acceptable to mix the two sets of terms?

I do not like "unnumbered" at all.

Cisco for instance has "interface unnumbered loopback0". This doesn't mean 
the interface doesn't have a number, it means it'll use the loopback0 
IPv4 address.

So I would much more prefer to say "link local only" interface or 
something to that effect. That would avoid confusion.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 11 Mar 2015 11:03:08 +0000

> We're already on the way...  expecting a long linguistic treaty next.

As we've only had 23 emails so far on this topic, I'm going to chip in my 2
eurocents:  namely, whatever is chosen, I politely suggest that we put some
html color tags in the draft to let posterity know how important this topic
is, and how seriously it was considered by the WG.  Also, the tags should
be red (#ff0000) to attract the appropriate level of attention.

We all understand it would be a mistake to let this issue be quietly
resolved without serious discussion, so it's only reasonable to make future
RFC readers aware of our heroic efforts to do what's best for them.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Mar 2015 08:44:03 +1300

Owen,

> In IPv6, there is no address scarcity, so I can’t see any upside whatsoever to either of these constructs.

Link-local addresses are a vital part of bootstrapping an IPv6 node,
especially in an unmanaged and unconfigured network; they will figure
largely in bootstrapping autonomic networks in particular.

They are viewed by some as also having an important security property:
they simply don't work off-link. draft-behringer-anima-autonomic-control-plane
takes this view, for example.

Unnumbered, in the literal sense, doesn't exist in IPv6, which is why
we are having this terminological discussion in the first place.

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Wed, 11 Mar 2015 19:14:01 -0700

> On Mar 11, 2015, at 12:44 , Brian E Carpenter <[email-masked]> wrote:
> 
> Owen,
> 

I’m not saying interfaces shouldn’t have a link local address. (jeez.)

I’m saying that not puting a real address on a link that shows up in traceroutes is a bad idea.

> takes this view, for example.

Blah blah blah.

> we are having this terminological discussion in the first place.

It doesn’t exist in IPv4 in the literal sense, either. As others have pointed out, what is called an
unnumbered interface in IPv4 is an interface that shares numbering with a loopback or other
interface which is an utter hack that yielded more confusion than useful results in the early efforts
to reduce IPv4 address consumption.

So, if you have something you don’t want to communicate off link AT ALL, then by all means,
go ahead and use link-local only numbering to your hearts content.

Otherwise, please put a real GUA on the interface to reduce the number of problems you inflict
on others when they have to troubleshoot something that involves/transits/originates from/etc.
your network.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Mar 2015 13:31:02 +0100

Le 12/03/2015 03:14, Owen DeLong a écrit :
>>> Link Local numbered interfaces are unlikely to be unambiguous
>>> when they appear in traceroutes. They are virtually guaranteed
>>> not to makes sense or provide useful information outside of your
>>> administrative domain.
>>>
>>> Unnumbered interfaces provide information only on which router
>>> received a packet, but not which interface. This can often be
>>> confusing, misleading, or outright useless when troubleshooting.
>>>
>>> In IPv6, there is no address scarcity, so I can’t see any upside
>>> whatsoever to either of these constructs.
>>
>> Link-local addresses are a vital part of bootstrapping an IPv6
>> node, especially in an unmanaged and unconfigured network; they
>> will figure largely in bootstrapping autonomic networks in
>> particular.
>

Yes and no.

YEs, we want traceroute to report an address of a hop, rather than a
three-star string "* * *".

But traceroute should be able to report link-local addresses, and ULAs,
as well.  If it doesnt then it's a problem of that traceroute program.

If an enduser needs rather globally-scoped and unique (rathern than LL
and ULA) addresses in traceroute outputs then one should ask her why?
Be them globally-scoped and unique they dont tell anything useful to a
human user of traceroute.  They surely dont tell _where_ these addresses
are (like in 'what country').

An address present in a traceroute output tells many things _if_ that
end user has an mental association of the address set out-of-band (like
"all addresses starting 2a02 belong to the operator I trust").  But
these out-of-band associations have no requirement whatsoever on the
scope of the address, or its uniqueness across Internet, or
prefix-middle-suffix position of the trusted incantation.  One could
very well have fe80:X:1 displayed by traceroute, and know out-of-band
that when X is in the address then the operator is trusted. (e.g.
X==face:b00c).

Besides, traceroute output is hugely more meaningful when it does not
display addresses but FQDNs.  These FQDNs have nothing to do with
address scope either.

Alex

>
>> They are viewed by some as also having an important security
>> property: they simply don't work off-link.
>> draft-behringer-anima-autonomic-control-plane takes this view, for
>> example.
>
> Blah blah blah.
>
>> Unnumbered, in the literal sense, doesn't exist in IPv6, which is
>> why we are having this terminological discussion in the first
>> place.
>
> It doesn’t exist in IPv4 in the literal sense, either. As others
> have pointed out, what is called an unnumbered interface in IPv4 is
> an interface that shares numbering with a loopback or other
> interface which is an utter hack that yielded more confusion than
> useful results in the early efforts to reduce IPv4 address
> consumption.
>
> So, if you have something you don’t want to communicate off link AT
> ALL, then by all means, go ahead and use link-local only numbering
> to your hearts content.
>
> Otherwise, please put a real GUA on the interface to reduce the
> number of problems you inflict on others when they have to
> troubleshoot something that involves/transits/originates from/etc.
> your network.
>
> Owen
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Mar 2015 13:39:27 +0100

Le 10/03/2015 22:53, joel jaeggli a écrit :
> for (responding to traceroute for example).

Is there a traceroute program that works with ll addresses?

Alex

  and some thing link local is

---

From: [email-masked]
Date: Thu, 12 Mar 2015 13:41:33 +0100 (CET)

> as well.  If it doesnt then it's a problem of that traceroute program.

Of course traceroute can report them. They are just not very helpful.

> are (like in 'what country').

Getting globally-scoped and unique addresses in the answer is a very
important part of what I use traceroute for. I strongly disagree with
the claim that "they dont tell anything useful to a human user of
traceroute". In most cases it is the PTR lookups for these addresses
that actually have the most interesting information - but not always.
The IP addresses themselves are also interesting, and can be used for
further rounds of traceroute, for instance. They can also be looked up
through the various RIRs etc.

> display addresses but FQDNs.  These FQDNs have nothing to do with

Surely they do. I cannot get a meaningful PTR lookup for a link-local
address. I *can* in many cases get a meaningful PTR lookup for a
globally-scoped address.

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Mar 2015 13:48:36 +0100

> they appear in traceroutes.

Addresses in traceroutes are always ambiguous.

It is a fallacy to think these addresses in traceroutes tell anything.

In the early era of IPv4 deployment, when could enumerate by hand the
deployed address spaces, maybe a traceroute could mean somehting to
these all-knowing persons...

> They are virtually guaranteed not to makes sense or provide useful
> information outside of your administrative domain.

No, they may make sense.  It depends who and how sets these LL addresses
on interfaces.  One could very well put
fe80:enteprise-name-coded-in-hexa::1 in each interface, or have that in
DNS, and a LL-reporting traceroute program.

> received a packet, but not which interface.

I agree.  A traceroute  output won't tell on which interface, or whether 
incoming or outgoing.

> This can often be confusing, misleading, or outright useless when
> troubleshooting.

To me this is just a bit misleading.

> whatsoever to either of these constructs.

Depends who you talk to.  Recently I talked to people who think scarcity 
is there in IPv6 as well.

Somebody who got assigned a /56 for herself will have a hard time to 
delegate further a /64, be it a single and unique /64.

Alex

>> operations.  It is a different protocol, after all.  Lots of
>> paradigms are different, most especially that of addressing.  Even
>> though I gather there is substantial support for calling those
>> links "unnumbered" on the basis of familiarity, Mark is completely
>> right in saying that this is the kind of thing that causes
>> confusion and oversight later on, and would create something
>> unintuitive to future network engineers in a world where IPv6 is
>> dominant.  The difference whereby no IPv4 address is borrowed (and
>> instead a link-local address is used) is sufficient to make this a
>> very different configuration.
>>
>> --Falcon Darkstar Momot --Shadytel
>>
>>> I'll also point out that I completely understand why it is
>>> occurred. It is easier for people to learn things based on
>>> things that are similar to what they know, and link-local only
>>> IPv6 links are conceptually quite similar to IPv4 unnumbered
>>> links.
>>>
>>> Of course there are also differences, and when something is
>>> different, we give it a different name to distinguish it (or a
>>> qualifier, however "link-local numbered, unnumbered links" is
>>> pretty clumsy (!))
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- From: Philip Matthews
>>> <[email-masked]> To: v6ops list <[email-masked]> Cc:
>>> Victor Kuarsingh <[email-masked]>; Mark ZZZ Smith
>>> <[email-masked]> Sent: Wednesday, 11 March 2015, 1:52
>>> Just want to get some direct feedback from the WG on the use of
>>> the terms "unnumbered interface" and "unnumbered link" in IPv6.
>>>
>>> Mark Smith, in some comments on the Design Choices draft , has
>>> said that he prefers the terms "interface with only link-local
>>> address" or "link with only link-local addresses" instead.   See
>>> the thread with title "I-D Action:
>>> draft-ietf-v6ops-design-choices-04.txt".
>>>
>>> What does the WG think?  Should we use the "unnumbered" terms,
>>> or should we use just the "... with only link-local address"
>>> terms? Is it acceptable to mix the two sets of terms?
>>>
>>> Philip
>>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Mar 2015 13:49:37 +0100

Le 11/03/2015 11:17, Mikael Abrahamsson a écrit :
>> Just want to get some direct feedback from the WG on the use of the
>> terms "unnumbered interface" and "unnumbered link" in IPv6.
>>
>> Mark Smith, in some comments on the Design Choices draft , has said
>> that he prefers the terms "interface with only link-local address" or
>> "link with only link-local addresses" instead.   See the thread with
>> title "I-D Action: draft-ietf-v6ops-design-choices-04.txt".
>>
>> should we use just the "... with only link-local address" terms?  Is
>> it acceptable to mix the two sets of terms?
>

I agree I dont like it either.

It's as if there were no numbers there.

Alex

> Cisco for instance has "interface unnumbered loopback0". This doesn't
> mean the interface doesn't have a number, it means it'll use the
> loopback0 IPv4 address.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Mar 2015 13:55:06 +0100

> through the various RIRs etc.

I think none of these can-do things can not be done with link-local 
addresses.

You can have reverse DNS lookups for LL addresses, you can have LL 
addresses in the RIR allocation databases (maybe as comments), etc.

> address. I *can* in many cases get a meaningful PTR lookup for a

But a LL address can be in the DNS also.  It has not been put there in 
some particular case, but nothing stops it to be there.

Alex

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Mar 2015 13:58:53 +0100

Hi,

> Is there a traceroute program that works with ll addresses?

This questions says a lot more than any possible answer could.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Mar 2015 14:00:53 +0100

Hi,

> Of course traceroute can report them. They are just not very helpful.

While *traceroute* would be able to report anything, no router worth its
money should ever send a packet with a LLA source off a link.  So you
should never see any packets that traceroute could report about.

That is, sort of, what the "local" in "local-scoped" is about, no?

Gert Doering
        -- NetMaster

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Mar 2015 14:03:54 +0100

> This questions says a lot more than any possible answer could.

What does it say?

Alex

---

From: [email-masked]
Date: Thu, 12 Mar 2015 14:06:37 +0100 (CET)

> should never see any packets that traceroute could report about.

Agreed. I'm just commenting on the claim that link-local addresses 
would be good for traceroute - a claim I strongly disagree with.

Steinar Haug, AS 2116

---

From: [email-masked]
Date: Thu, 12 Mar 2015 14:11:11 +0100 (CET)

> It is a fallacy to think these addresses in traceroutes tell anything.

You are of course free to believe that. Meanwhile, I plan to continue
using traceroute as a useful tool, keeping in mind the valuable advice
from Richard Steenbergen's Nanog presentation at

https://www.nanog.org/sites/default/files/tuesday_steenbergen_troublshootingtraceroute_62.49.pdf

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Mar 2015 14:14:53 +0100

Le 12/03/2015 14:00, Gert Doering a écrit :
>>> But traceroute should be able to report link-local addresses, and
>>> ULAs, as well.  If it doesnt then it's a problem of that
>>> traceroute program.
> While *traceroute* would be able to report anything, no router worth
> its money should ever send a packet with a LLA source off a link.

Well, a router should not _forward_ such a packet, but it could always
issue one, why not?

Apps with beaconing semantics, or video stream (no need of reply), may 
use this.

> So you should never see any packets that traceroute could report
> about.

Traceroute is a diagnostic program.  I think you have no RFC that 
specifies how traceroute acts.

You can write a 'traceroute' program that reports LL addresses, I dont 
see a problem in that.

> That is, sort of, what the "local" in "local-scoped" is about, no?

It's local for locally-scoped protocols.  But I can very well have a web 
page telling me all the addresses of a very distant router (many IP hops 
away), including its link-local addresses.

LL addresses can be present in payloads w/o problem.

LL addresses can be present in IPv6 Routing Header.

With this at hand a 'traceroute' program can report LL addresses.

Alex

>
> Gert Doering -- NetMaster
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Mar 2015 14:22:41 +0100

Le 12/03/2015 14:11, [email-masked] a écrit :
>>> when they appear in traceroutes.
>>
> using traceroute as a useful tool,

I agree, Traceroute is a hugely useful tool.

But its existence should not mean LL-only links should not exist.

It's as if we said that yahoo (the address) should not exist because
firefox (the tool) homes into a google page: firefox could home into a
yahoo page as well.

LL addresses could have as much semantics in them as globally-scoped
addresses.

> keeping in mind the valuable advice from Richard Steenbergen's Nanog
> presentation at
>

Thanks for the pointer.  YEs, this is precisely the kind of out-of-band
info that is useful to a traceroute user.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Mar 2015 10:40:28 -0700

[snip]

> three-star string "* * *”.

No… We want traceroute to report an address of a hop that has a valid binding
in ip6.arpa that tells people something meaningful about the hop, and, ideally,
the interface of arrival at said hop.

> as well.  If it doesnt then it's a problem of that traceroute program.

See above. Merely reporting an address that is utterly and completely meaningless
outside of the zone of administrative control (ULA) or outside of the local link (LL)
is less than helpful.

> are (like in 'what country’).

Well, the address being GUA alone is not the complete solution, but it is certainly
a necessary component. Obviously, the next step is to provide a useful mapping
in ip6.arpa as well.

For example:

owen.delong.com:owen /home4/owen (29) % traceroute6 www.facebook.com
traceroute to www.facebook.com (2a03:2880:10:cf07:face:b00c:0:1), 30 hops max, 80 byte packets
 1  2620:0:930:0:2e6b:f5ff:fe03:a80 (2620:0:930:0:2e6b:f5ff:fe03:a80)  1.788 ms  1.777 ms  1.787 ms
 2  owen-2.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1f03:9c::1)  12.973 ms  19.452 ms  20.374 ms
 3  ge4-22.core2.fmt1.he.net (2001:470:0:1f::1)  28.750 ms  29.679 ms  29.739 ms
 4  ge5-15.core1.fmt2.he.net (2001:470:0:1bc::1)  20.313 ms  20.331 ms  20.337 ms
 5  10ge1-1.core1.sjc2.he.net (2001:470:0:31::2)  20.332 ms * *
 6  * facebook.gige-g5-9.core1.sjc2.he.net (2001:470:0:14a::2)  18.399 ms  18.371 ms
 7  ae1.bb03.sjc1.tfbnw.net (2620:0:1cff:dead:beef::c5a)  18.370 ms  24.237 ms  14.423 ms
 8  ae24.bb04.prn2.tfbnw.net (2620:0:1cff:dead:beef::c32)  33.334 ms  32.289 ms  33.340 ms
 9  ae4.dr05.prn1.tfbnw.net (2620:0:1cff:dead:beef::68d)  39.411 ms ae13.dr05.prn1.tfbnw.net (2620:0:1cff:dead:beef::69d)  39.557 ms ae4.dr02.prn1.tfbnw.net (2620:0:1cff:dead:beef::69b)  38.365 ms
10  po1019.csw12a.prn1.tfbnw.net (2620:0:1cff:dead:beef::1769)  48.094 ms po1021.csw12d.prn1.tfbnw.net (2620:0:1cff:dead:beef::1785)  39.399 ms po1019.csw12b.prn1.tfbnw.net (2620:0:1cff:dead:beef::1775)  39.348 ms
11  * * *
12  edge-star6-shv-12-prn1.facebook.com (2a03:2880:10:cf07:face:b00c:0:1)  37.765 ms  38.419 ms  36.471 ms

Hop 1 doesn’t provide useful information, but it’s the SLAAC address of the interior side of a local router, so it’s only going to be seen on outbound traceroutes from my small site.

The other hops do provide useful ip6.arpa mappings (with the obvious exception of hop 11 which doesn’t respond at all, probably a load balancer at FB).

I can tell from the information provided by the various operators that my packet is delivered to an HE tunnelserver in their Fremont 1 datacenter, then forwarded to a core router in that same datacenter, over to their Fremont 2 datacenter, etc.

I can even tell that on the core router in Fremont 1, my packet arrived on gigabit ethernet interface card 4 port 22. I can also see interface information on the remaining hops as well.

The vast majority of providers put this information into ip6.arpa to make their lives easier when it comes to troubleshooting, but it also happens to make life easier for external users as well.

> that when X is in the address then the operator is trusted. (e.g.

Actually, they do.

If I build a mental association of “all addresses starting with fd0c:face:b00c::” belong
to Face Book, not only am I an idiot for trusting some sort of association between
ULA and a particular organization, but I’m also quite likely to be wrong some significant
portion of the time.

> display addresses but FQDNs.  These FQDNs have nothing to do with

Yes, they do. You can’t (legitimately) create externally visible ip6.arpa records
for addresses that are not GUA scoped. If you think that you can, please share
whatever you are smoking.

Owen

>> [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Mar 2015 10:46:29 -0700

> On Mar 12, 2015, at 05:55 , Alexandru Petrescu <[email-masked]> wrote:
> 
> Le 12/03/2015 13:41, [email-masked] <mailto:[email-masked]> a écrit :
> I think none of these can-do things can not be done with link-local addresses.
> 
> You can have reverse DNS lookups for LL addresses, you can have LL addresses in the RIR allocation databases (maybe as comments), etc.

I personally guarantee you that no RIR whois server is going to respond usefully to a query for an address starting in fe80:: any time soon.

I can also guarantee you that attempts to get any portion of 0.8.e.f.ip6.arpa delegated to your nameserver by any of the RIRs are also not likely to succeed.

Given that, how, exactly, do you propose that your above statements can possible be true?

> But a LL address can be in the DNS also.  It has not been put there in some particular case, but nothing stops it to be there.

Not in a useful way it cannot. Sure, you can create an 0.8.e.f.ip6.arpa zone within your DNS server and answer queries that arrive there, but anyone outside of your administrative control is unlikely to ask your server for that information. The RIRs are not going to delegate NS for any portion of 0.8.e.f.ip6.arpa, and I expect neither will IANA or IETF.

We’re talking about a global internet here, not some isolated LAN segment. If it’s an isolated LAN segment do whatever you want, the IETF doesn’t care. You don’t need an RFC. RFCs and the IETF process are for developing standards for cooperating networks participating in a global internet. If you aren’t one of those, then you can follow or not follow them as you wish on your non-connected network.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Mar 2015 10:52:14 -0700

> On Mar 12, 2015, at 06:14 , Alexandru Petrescu <[email-masked]> wrote:
> 
> Apps with beaconing semantics, or video stream (no need of reply), may use this.
> 
> Traceroute is a diagnostic program.  I think you have no RFC that specifies how traceroute acts.
> 
> You can write a 'traceroute' program that reports LL addresses, I dont see a problem in that.

Here’s the problem…

Traceroute depends on receiving ICMP HOP_COUNT_EXCEEDED messages with the hop address embedded in the SRC field of the ICMP datagram.

If you are running traceroute on a machine that is not adjacent to the hop responding with said message from a LL source address, then you will never see the packet because NONE of the routers between it and you should forward said packet to a different interface from the one it arrived on.

So, traceroute may report whatever it receives, but it CANNOT receive a packet with a LL Source address from a non-adjacent router unless all of the routers in between violate the RFCs regarding forwarding of LL packets.

> It's local for locally-scoped protocols.  But I can very well have a web page telling me all the addresses of a very distant router (many IP hops away), including its link-local addresses.

Sure, but you’ll never get the LL address in your traceroute to look up, so I think the web page is moot.

> LL addresses can be present in payloads w/o problem.

Yes, but traceroute doesn’t use the payload.

> LL addresses can be present in IPv6 Routing Header.

Yes, but I’m not sure how that applies here, nor am I sure it is useful for them to appear there.

> With this at hand a 'traceroute' program can report LL addresses.

Not the way traceroute programs currently work. I think you would be hard pressed to create a traceroute program that could do so without modifying code on virtually every deployed IPv6 router as well.

Owen

---

From: "Metzler, Dan J" <[email-masked]>
Date: Thu, 12 Mar 2015 19:25:23 +0000

I don't understand this discussion.  I thought the topic  was a terminology discussion about whether to use the term "un-numbered" when referring to an interface that only has a link-local address.

Traceroute should work with link-local addresses, but only when you target a link-local address.
(It won't go off link, so either that address is a neighbor or it is not reachable, and traceroute probably reflects that already.)
Same thing with ULA.  If you actually use the ULA in the traceroute command or it's in the route, then I would think it already shows up.
If not, you aren't going to see it.

To me, the term "un-numbered" doesn't make much sense because the interface has a link-local address.

- Dan

> From: v6ops [mailto:[email-masked]] On Behalf Of Owen DeLong
> Sent: Thursday, March 12, 2015 12:52 PM
> To: Alexandru Petrescu
> Cc: [email-masked]
> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?
> 
> 
> >>>> ULAs, as well.  If it doesnt then it's a problem of that traceroute
> >>>> program.
> Here's the problem.
> Traceroute depends on receiving ICMP HOP_COUNT_EXCEEDED messages with
> the hop address embedded in the SRC field of the ICMP datagram.
> 
> If you are running traceroute on a machine that is not adjacent to the hop
> responding with said message from a LL source address, then you will never
> see the packet because NONE of the routers between it and you should
> forward said packet to a different interface from the one it arrived on.
> 
> So, traceroute may report whatever it receives, but it CANNOT receive a
> packet with a LL Source address from a non-adjacent router unless all of the
> routers in between violate the RFCs regarding forwarding of LL packets.
> 
> > It's local for locally-scoped protocols.  But I can very well have a web page
> telling me all the addresses of a very distant router (many IP hops away),
> including its link-local addresses.
> 
> Sure, but you'll never get the LL address in your traceroute to look up, so I
> think the web page is moot.
> 
> Yes, but traceroute doesn't use the payload.
> 
> Yes, but I'm not sure how that applies here, nor am I sure it is useful for them
> to appear there.
> 
> Not the way traceroute programs currently work. I think you would be hard
> pressed to create a traceroute program that could do so without modifying
> code on virtually every deployed IPv6 router as well.
> 
> Owen
> 
> >
> > Alex
> >
> >>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Mar 2015 10:47:51 +1300

Alex,
> Le 12/03/2015 14:00, Gert Doering a écrit :
...
> It's local for locally-scoped protocols.  But I can very well have a web page telling me all the addresses of a very distant
> router (many IP hops away), including its link-local addresses.

Theoretically, such a thing could exist, but I can't imagine any
ISP that cares about protecting its infrastructure from bad actors
doing such a thing.

> LL addresses can be present in payloads w/o problem.

They are explicitly meaniningless off the link. With a Zone ID
attached, they are explicitly meaningless off the host. So putting
them in a payload is almost always problematic. (And yes, I'm aware
of the problem for CUPS caused by RFC6874.)

> LL addresses can be present in IPv6 Routing Header.

Indeed; I am contemplating whether it's worth a draft specifically
forbidding this.

> With this at hand a 'traceroute' program can report LL addresses.

It can, and they are useless.

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 12 Mar 2015 23:38:53 +0000 (UTC)

I'd also think 'locally-numbered' doesn't have enough clarity, because it could sound general enough that it covers/describes Unique Local Addressing.
I think "link-local only" is the most accurate description e.g. "link-local only links", "link-local only addressing".
      From: Erik Kline <[email-masked]>
 To: Falcon Darkstar Momot <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
 Sent: Wednesday, 11 March 2015, 18:51
 Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 12 Mar 2015 23:43:55 +0000 (UTC)

If you don't ensure clarity and accuracy, simple misunderstandings can have catastrophic consequences :

"NASA's metric confusion caused Mars orbiter loss - September 30, 1999"

http://edition.cnn.com/TECH/space/9909/30/mars.metric/

________________________________
From: Nick Hilliard <[email-masked]>
To: Gert Doering <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Wednesday, 11 March 2015, 22:03
Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?

Nick

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 12 Mar 2015 23:54:12 +0000 (UTC)

----- Original Message -----
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Thursday, 12 March 2015, 23:41
Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?

/ Actually, as LLs have 64 bit IIDs, you could create network wide unique LL IIDs for all of your router interfaces such that PTRs for them would be unambiguous. A forward AAAA for the PTR answer could then provide the OAM loopback for ssh etc. purposes.

/ I would normally avoid link-local only links in a network, however if I was in a situation where they would be the best choice, then I'd doing things to make them more usable such as creating network wide unique LL IIDs.

Steinar Haug, AS 2116

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Fri, 13 Mar 2015 03:23:04 -0700

> Indeed; I am contemplating whether it's worth a draft specifically

Surely not.  However, it does remind me of martian packets a little bit, 
and maybe a larger draft could consolidate security practices for IPv6, 
such as filtering packets with ridiculous routing headers such as those 
where the address might actually be used for routing, inter alia.

--Falcon Darkstar Momot
--Shadytel

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Fri, 13 Mar 2015 04:04:42 -0700

Ok, how about just "link-numbered"?  Nobody could confuse that with ULA 
or RFC1918 or IPv4-style unnumbered links, and it should be intuitive to 
anyone who knows how IPv6 addresses work.

On 2015-03-12 16:38, Mark ZZZ Smith wrote:
> I'd also think 'locally-numbered' doesn't have enough clarity, because 
> it could sound general enough that it covers/describes Unique Local 
> Addressing.
>
> I think "link-local only" is the most accurate description e.g. 
> "link-local only links", "link-local only addressing".
>
> ------------------------------------------------------------------------
> *From:* Erik Kline <[email-masked]>
> *To:* Falcon Darkstar Momot <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Wednesday, 11 March 2015, 18:51
> *Subject:* Re: [v6ops] Should we use "unnumbered" in IPv6?
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Mar 2015 12:33:05 +0100

Le 12/03/2015 18:40, Owen DeLong a écrit :
>> YEs, we want traceroute to report an address of a hop, rather than
>> a three-star string "* * *”.
>
> No… We want traceroute to report an address of a hop that has a
> valid binding in ip6.arpa that tells people something meaningful
> about the hop, and, ideally, the interface of arrival at said hop.
>
> See above. Merely reporting an address that is utterly and
> completely meaningless outside of the zone of administrative control
> (ULA) or outside of the local link (LL) is less than helpful.

It depends what is in that address.  It's its scope which does not matter.

>> If an enduser needs rather globally-scoped and unique (rathern
>> than LL and ULA) addresses in traceroute outputs then one should
>> ask her why? Be them globally-scoped and unique they dont tell
>> anything useful to a human user of traceroute.  They surely dont
>> tell _where_ these addresses are (like in 'what country’).
>
> Well, the address being GUA alone is not the complete solution, but
> it is certainly a necessary component.

The address being a GUA (and not a LL) is an artifact of porting
traceroute from IPv4 to IPv6.  A native IPv6 traceroute would report LLs
as well.  And be ported back to IPv4 to report IPv4 LLs.

> Obviously, the next step is to provide a useful mapping in ip6.arpa
> as well.

Yes.

> <http://www.facebook.com> traceroute to www.facebook.com
> <http://www.facebook.com> (2a03:2880:10:cf07:face:b00c:0:1), 30 hops
> max, 80 byte packets 1  2620:0:930:0:2e6b:f5ff:fe03:a80
> (2620:0:930:0:2e6b:f5ff:fe03:a80) 1.788 ms  1.777 ms  1.787 ms 2
> owen-2.tunnel.tserv2.fmt.ipv6.he.net <http://fmt.ipv6.he.net>
> (2001:470:1f03:9c::1)  12.973 ms  19.452 ms  20.374 ms 3
> ge4-22.core2.fmt1.he.net <http://ge4-22.core2.fmt1.he.net>
> (2001:470:0:1f::1)  28.750 ms  29.679 ms  29.739 ms 4
> ge5-15.core1.fmt2.he.net <http://ge5-15.core1.fmt2.he.net>
> (2001:470:0:1bc::1)  20.313 ms  20.331 ms  20.337 ms 5
> 10ge1-1.core1.sjc2.he.net <http://10ge1-1.core1.sjc2.he.net>
> (2001:470:0:31::2)  20.332 ms * * 6  *
> facebook.gige-g5-9.core1.sjc2.he.net <http://g5-9.core1.sjc2.he.net>
> (2001:470:0:14a::2)  18.399 ms  18.371 ms 7 ae1.bb03.sjc1.tfbnw.net
> <http://ae1.bb03.sjc1.tfbnw.net> (2620:0:1cff:dead:beef::c5a) 18.370
> ms  24.237 ms  14.423 ms 8 ae24.bb04.prn2.tfbnw.net
> <http://ae24.bb04.prn2.tfbnw.net> (2620:0:1cff:dead:beef::c32) 33.334
> ms  32.289 ms  33.340 ms 9 ae4.dr05.prn1.tfbnw.net
> <http://ae4.dr05.prn1.tfbnw.net> (2620:0:1cff:dead:beef::68d) 39.411
> ms ae13.dr05.prn1.tfbnw.net <http://ae13.dr05.prn1.tfbnw.net>
> (2620:0:1cff:dead:beef::69d)  39.557 ms ae4.dr02.prn1.tfbnw.net
> <http://ae4.dr02.prn1.tfbnw.net> (2620:0:1cff:dead:beef::69b) 38.365
> ms 10 po1019.csw12a.prn1.tfbnw.net
> <http://po1019.csw12a.prn1.tfbnw.net> (2620:0:1cff:dead:beef::1769)
> 48.094 ms po1021.csw12d.prn1.tfbnw.net
> <http://po1021.csw12d.prn1.tfbnw.net> (2620:0:1cff:dead:beef::1785)
> 39.399 ms po1019.csw12b.prn1.tfbnw.net
> <http://po1019.csw12b.prn1.tfbnw.net> (2620:0:1cff:dead:beef::1775)
> 39.348 ms 11  * * * 12 edge-star6-shv-12-prn1.facebook.com
> <http://edge-star6-shv-12-prn1.facebook.com>
> (2a03:2880:10:cf07:face:b00c:0:1)  37.765 ms  38.419 ms  36.471 ms
>
>
> Hop 1 doesn’t provide useful information, but it’s the SLAAC address
> of the interior side of a local router,

You see, why do you call it a SLAAC address?

It's unsafe to assume ff:fe and global prefix means SLAAC.

The randomly generated addresses, the DHCP, or the imaginative
sysadmins, may have put the same ff:fe in there.  ff:fe is not forbidden
to DHCP, to sysadmins and to the random generation of privacy addresses.

> so it’s only going to be seen on outbound traceroutes from my small
> site.
>
> The other hops do provide useful ip6.arpa mappings (with the obvious
> exception of hop 11 which doesn’t respond at all, probably a load
> balancer at FB).
>
> I can tell from the information provided by the various operators
> that my packet is delivered to an HE tunnelserver in their Fremont 1
> datacenter, then forwarded to a core router in that same datacenter,
> over to their Fremont 2 datacenter, etc.

Except that traceroute does not tell for each tunnel its 4 addresses.

> I can even tell that on the core router in Fremont 1, my packet
> arrived on gigabit ethernet interface card 4 port 22. I can also see
> interface information on the remaining hops as well.
>
> The vast majority of providers put this information into ip6.arpa to
> make their lives easier when it comes to troubleshooting, but it also
> happens to make life easier for external users as well.

Ok.

>> An address present in a traceroute output tells many things _if_
>> that end user has an mental association of the address set
>> out-of-band (like "all addresses starting 2a02 belong to the
>> operator I trust").  But these out-of-band associations have no
>> requirement whatsoever on the scope of the address, or its
>> uniqueness across Internet, or prefix-middle-suffix position of
>> the trusted incantation.  One could very well have fe80:X:1
>> displayed by traceroute, and know out-of-band that when X is in the
>> address then the operator is trusted. (e.g. X==face:b00c).
>
> Actually, they do.
>
> If I build a mental association of “all addresses starting with
> fd0c:face:b00c::” belong to Face Book, not only am I an idiot for
> trusting some sort of association between ULA and a particular
> organization, but I’m also quite likely to be wrong some significant
>  portion of the time.

You make a good supposition.  There is no guarantee but it's likely to 
be the case.  It's the same level of confidence in assuming 
2a01:face:b00c:: belongs to facebook.  The scope does not matter, there 
is no difference between global or local scope.

>> Besides, traceroute output is hugely more meaningful when it does
>> not display addresses but FQDNs.  These FQDNs have nothing to do
>> with address scope either.
>
> Yes, they do. You can’t (legitimately) create externally visible
> ip6.arpa records for addresses that are not GUA scoped. If you think
> that you can, please share whatever you are smoking.

Do you mean that DNS requests are blocked if the parameter starts with 
"fe80"?

Alex

>>>> draft-behringer-anima-autonomic-control-plane takes this view,
>>>> for example.
>>>
>>> Blah blah blah.
>>>
>>>> Unnumbered, in the literal sense, doesn't exist in IPv6, which
>>>> is why we are having this terminological discussion in the
>>>> first place.
>>>
>>>  have pointed out, what is called an unnumbered interface in
>>> IPv4 is an interface that shares numbering with a loopback or
>>> other interface which is an utter hack that yielded more
>>> confusion than useful results in the early efforts to reduce IPv4
>>> address consumption.
>>>
>>> So, if you have something you don’t want to communicate off link
>>> AT ALL, then by all means, go ahead and use link-local only
>>> numbering to your hearts content.
>>>
>>> troubleshoot something that involves/transits/originates
>>> from/etc. your network.
>>>
>>> Owen
>>>
>>> list [email-masked]
>>> <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>
>>
>>>
>>>
>>>
>>>
>> v6ops mailing list [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Mar 2015 12:41:39 +0100

Le 12/03/2015 18:46, Owen DeLong a écrit :
>
>> On Mar 12, 2015, at 05:55 , Alexandru Petrescu
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Le 12/03/2015 13:41,[email-masked] <mailto:[email-masked]>a
>> écrit :
>>>> YEs, we want traceroute to report an address of a hop, rather
>>>> than a three-star string "* * *".
>>>>
>>>> But traceroute should be able to report link-local addresses,
>>>> and ULAs, as well.  If it doesnt then it's a problem of that
>>>> traceroute program.
>>>
>>>> than LL and ULA) addresses in traceroute outputs then one
>>>> should ask her why? Be them globally-scoped and unique they
>>>> dont tell anything useful to a human user of traceroute.  They
>>>> surely dont tell _where_ these addresses are (like in 'what
>>>> country').
>>>
>>> Getting globally-scoped and unique addresses in the answer is a
>>> very important part of what I use traceroute for. I strongly
>>> disagree with the claim that "they dont tell anything useful to a
>>> human user of traceroute". In most cases it is the PTR lookups
>>> for these addresses that actually have the most interesting
>>> information - but not always. The IP addresses themselves are
>>> also interesting, and can be used for further rounds of
>>> traceroute, for instance. They can also be looked up through the
>>> various RIRs etc.
>>
> I personally guarantee you that no RIR whois server is going to
> respond usefully to a query for an address starting in fe80:: any
> time soon.

Well, it depends how the request is made and how me as owner ask the RIR
to put things in that database.  A RIR already puts my phone number in
that database - why not a link-local address crafted to my taste?

> I can also guarantee you that attempts to get any portion of
> 0.8.e.f.ip6.arpa delegated to your nameserver by any of the RIRs are
>  also not likely to succeed.

I agree.

> Given that, how, exactly, do you propose that your above statements

I can always tell people to use my public DNS server if they want to
LL-traceroute through my domain.

>>>> Besides, traceroute output is hugely more meaningful when it
>>>> does not display addresses but FQDNs.  These FQDNs have nothing
>>>> to do with address scope either.
>>>
>>> Surely they do. I cannot get a meaningful PTR lookup for a
>>> link-local address. I *can* in many cases get a meaningful PTR
>>> lookup for a globally-scoped address.
>>
>> But a LL address can be in the DNS also.  It has not been put there
>> in some particular case, but nothing stops it to be there.
>
> Not in a useful way it cannot. Sure, you can create an
> 0.8.e.f.ip6.arpa zone within your DNS server and answer queries that
> arrive there, but anyone outside of your administrative control is
> unlikely to ask your server for that information. The RIRs are not
> going to delegate NS for any portion of 0.8.e.f.ip6.arpa, and I
> expect neither will IANA or IETF.

YEs, but there are other perspectives as well.

For example, google does not ask people to be under their adminsitrative
control, but offer this 8.8.8.8 DNS server, and it's used extensively.

> We’re talking about a global internet here,

'Global' Internet?  What's the DNS server that could accept arbitrary 
requests in this global Internet?  There isn't any which has no 
commercial interest in a _local_ business.

> not some isolated LAN segment. If it’s an isolated LAN segment do
> whatever you want, the IETF doesn’t care. You don’t need an RFC. RFCs
> and the IETF process are for developing standards for cooperating
> networks participating in a global internet. If you aren’t one of
> those, then you can follow or not follow them as you wish on your
> non-connected network.

Ok, but I will refrain from further commenting on this DNS aspect and 
its locality.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Mar 2015 12:48:52 +0100

Le 12/03/2015 18:52, Owen DeLong a écrit :
>>> While *traceroute* would be able to report anything, no router
>>> worth its money should ever send a packet with a LLA source off a
>>> link.
>>
>> Well, a router should not _forward_ such a packet, but it could
>> always issue one, why not?
>>

HOP_COUNT_EXCEEDED is a way of traceing a route.  There are other ways 
in which do trace routes.

ICMP_HOP_COUNT_EXCEEDED may be forbidden by some routers as well.

> If you are running traceroute on a machine that is not adjacent to
> the hop responding with said message from a LL source address, then
> you will never see the packet because NONE of the routers between it
> and you should forward said packet to a different interface from the
> one it arrived on.
>
> So, traceroute may report whatever it receives, but it CANNOT receive
> a packet with a LL Source address from a non-adjacent router unless
> all of the routers in between violate the RFCs regarding forwarding
> of LL packets.

Ok.

>> It's local for locally-scoped protocols.  But I can very well have
>> a web page telling me all the addresses of a very distant router
>> (many IP hops away), including its link-local addresses.
>
> Not the way traceroute programs currently work. I think you would be
> hard pressed to create a traceroute program that could do so without
> modifying code on virtually every deployed IPv6 router as well.

I agree.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Mar 2015 12:53:10 +0100

Le 12/03/2015 20:25, Metzler, Dan J a écrit :
> I don't understand this discussion.  I thought the topic  was a
> terminology discussion about whether to use the term "un-numbered"
> when referring to an interface that only has a link-local address.

My point was to say that traceroute needing GUAs should not mean the
links without GUAs (hence 'unnumbered') should not exist.

To put it other way, links without GUAs are there, and a name for them
shoudl be found.

> Traceroute should work with link-local addresses, but only when you
> target a link-local address. (It won't go off link, so either that
> address is a neighbor or it is not reachable, and traceroute probably
> reflects that already.)

Yes.

> Same thing with ULA.  If you actually use the ULA in the traceroute
> command or it's in the route, then I would think it already shows
> up. If not, you aren't going to see it.

If LLs dont show in traceroute output because not on same link then ULA
will not show either, unless in the same domain.

I agree.

>
> - Dan
>
>> -----Original Message----- From: v6ops
>> [mailto:[email-masked]] On Behalf Of Owen DeLong Sent:
>> Thursday, March 12, 2015 12:52 PM To: Alexandru Petrescu Cc:
>> [email-masked] Subject: Re: [v6ops] Should we use "unnumbered" in
>> IPv6?
>>
>>
>>>>>> But traceroute should be able to report link-local
>>>>>> addresses, and ULAs, as well.  If it doesnt then it's a
>>>>>> problem of that traceroute program.
>>>>  worth its money should ever send a packet with a LLA source
>>>> off a link.
>>>
>>> Apps with beaconing semantics, or video stream (no need of
>>> reply), may use
>> this.
>>>
>>>> So you should never see any packets that traceroute could
>>>> report about.
>>>
>>> You can write a 'traceroute' program that reports LL addresses, I
>>> dont see a
>> problem in that.
>>
>> Here's the problem.
>>
>> Traceroute depends on receiving ICMP HOP_COUNT_EXCEEDED messages
>> with the hop address embedded in the SRC field of the ICMP
>> datagram.
>>
>>  the hop responding with said message from a LL source address,
>> then you will never see the packet because NONE of the routers
>> between it and you should forward said packet to a different
>> interface from the one it arrived on.
>>
>> So, traceroute may report whatever it receives, but it CANNOT
>> receive a packet with a LL Source address from a non-adjacent
>> router unless all of the routers in between violate the RFCs
>> regarding forwarding of LL packets.
>>
>> telling me all the addresses of a very distant router (many IP hops
>> Sure, but you'll never get the LL address in your traceroute to
>> look up, so I think the web page is moot.
>>
>> Yes, but I'm not sure how that applies here, nor am I sure it is
>> useful for them to appear there.
>>
>> Not the way traceroute programs currently work. I think you would
>> be hard pressed to create a traceroute program that could do so
>> without modifying code on virtually every deployed IPv6 router as
>> well.
>>
>> Owen
>>
>>>
>>> Alex
>>>
>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Mar 2015 13:30:01 +0100

On this particular point.

[...]
> all of the routers in between violate the RFCs regarding forwarding

For example RFC4291 "Addr Architecture" forbids packets with src or dst
address to get away from a link.  It literraly says "Routers must not
forward any packets with Link-Local source or destination addresses to
other links."

Whereas the dst part reads best, I wonder whether the src part does not
amount a bit to ingress filtering.  Ingress filtering is a policy useful
in some security context, but is also seen as a bad technique that needs
to be overcome by some other technique.  Ingress filtering would not be
part of architectural thinking, but of policy thinking.

There may be, in some context, a need of a packet with a LL src address
and a GUA dst address.  This packet would be forwarded by routers,
although they may log it as an exceptional case.  But it should not be
dropped.

If this were done, then maybe traceroute programs which rely on the
chance of HOP_COUNT_EXCEEDED would report LLs as well.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 13 Mar 2015 13:42:31 +0100 (CET)

> although they may log it as an exceptional case.  But it should not be

Yes it should. RFC4291 says it MUST be dropped, with very good reason. We 
do not want LL (src or dst) packets being routed around.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Mar 2015 17:15:03 +0100

Le 13/03/2015 13:42, Mikael Abrahamsson a écrit :
>> Le 12/03/2015 18:52, Owen DeLong a écrit : [...]
>> For example RFC4291 "Addr Architecture" forbids packets with src
>> or dst address to get away from a link.  It literraly says
>> "Routers must not forward any packets with Link-Local source or
>> destination addresses to other links."
>>
>> Whereas the dst part reads best, I wonder whether the src part
>> does not amount a bit to ingress filtering.  Ingress filtering is
>> a policy useful in some security context, but is also seen as a
>> bad technique that needs to be overcome by some other technique.
>> Ingress filtering would not be part of architectural thinking, but
>> of policy thinking.
>>
>> There may be, in some context, a need of a packet with a LL src
>> address and a GUA dst address.  This packet would be forwarded by
>> routers, although they may log it as an exceptional case.  But it
>> should not be dropped.
>
> Yes it should. RFC4291 says it MUST be dropped, with very good
> reason. We do not want LL (src or dst) packets being routed around.

It's a good principle, one of the few still resisting to exceptions.

Maybe one thinks that lack of uniqueness guarantees by administrative
allocation, and lack of same-scope equipotency, may induce harm when
forwarding LL-src packets.

Yet packets with src ULA and dst GUA _are_ routed around.

Packets with src unicast and dst multicast _are_ routed around.

Packets with src LL and dst GUA multiple hops away from that link can be
helpful to some applications not needing replies (e.g. periodic beacons
of routing protocols, or of tunnel maintenance, or of NAT-state
maintenance during traversal).

I'd go as far as saying that packets with dst LL which is _one_ hop away
should be forwarded, because the Router is able to detect address
collisions on both its links.  Beyond one hop it would be a problem, but
forwarding LL across one hop should not break anything.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Mar 2015 16:22:14 +0000

Hi,

I am way out of context on this thread, but I wanted to ask the
following. It should be OK for a router to leave some of its links as
link-local-only as long as the router has at least one GUA that it can
use as the source address of any ICMPs it needs to send - right?

Thanks - Fred
[email-masked]

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Friday, March 13, 2015 9:15 AM
> To: Mikael Abrahamsson
> Cc: [email-masked]
> Subject: Re: [v6ops] Should we use "unnumbered" in IPv6? - RFCs forbidding LL away
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Mar 2015 17:32:11 +0100

Le 13/03/2015 17:22, Templin, Fred L a écrit :
> following. It should be OK for a router to leave some of its links
> as link-local-only as long as the router has at least one GUA that it
> can use as the source address of any ICMPs it needs to send - right?

I think yes, that would be sufficient to respect RFCs.

And yes, it makes ok to talk about ll-only links on which traceroute
still works (even though it reports the GUA not the LL).

It would not help traceroute to display LL addresses.

It would mean to ifconfig the same GUA on several of its interfaces; if
so the interface would no longer be LL-only, although the other side of
a link may be LL-only.  That link would be a link half-ll-only, or
'half-unnumbered' if I can say so.

Alex

>
> Thanks - Fred [email-masked]
>
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Friday, March 13, 2015 9:15 AM To: Mikael Abrahamsson Cc:
>> IPv6? - RFCs forbidding LL away
>>
>>>>> So, traceroute may report whatever it receives, but it
>>>>> CANNOT receive a packet with a LL Source address from a
>>>>> non-adjacent router unless all of the routers in between
>>>>> violate the RFCs regarding forwarding of LL packets.
>>>>
>>>> For example RFC4291 "Addr Architecture" forbids packets with
>>>> src or dst address to get away from a link.  It literraly says
>>>> "Routers must not forward any packets with Link-Local source
>>>> or destination addresses to other links."
>>>>
>>>> does not amount a bit to ingress filtering.  Ingress filtering
>>>> is a policy useful in some security context, but is also seen
>>>> as a bad technique that needs to be overcome by some other
>>>> technique. Ingress filtering would not be part of architectural
>>>> thinking, but of policy thinking.
>>>>
>>>> There may be, in some context, a need of a packet with a LL
>>>> src address and a GUA dst address.  This packet would be
>>>> forwarded by routers, although they may log it as an
>>>> exceptional case.  But it should not be dropped.
>>>
>> Maybe one thinks that lack of uniqueness guarantees by
>> administrative allocation, and lack of same-scope equipotency, may
>> induce harm when forwarding LL-src packets.
>>
>> Packets with src LL and dst GUA multiple hops away from that link
>> can be helpful to some applications not needing replies (e.g.
>> periodic beacons of routing protocols, or of tunnel maintenance, or
>> of NAT-state maintenance during traversal).
>>
>> I'd go as far as saying that packets with dst LL which is _one_ hop
>> away should be forwarded, because the Router is able to detect
>> address collisions on both its links.  Beyond one hop it would be a
>> problem, but forwarding LL across one hop should not break
>> anything.
>>
>> Alex
>>
>>>
>>
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Mar 2015 16:43:25 +0000

Hi Alex,

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Friday, March 13, 2015 9:32 AM
> To: Templin, Fred L; Mikael Abrahamsson
> Cc: [email-masked]

I am thinking of a router that pins a GUA on some sort of internal virtual
interface (like a loopback) but leaves all of its other interfaces as link
local only. Do you see a problem with that?

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Mar 2015 17:51:45 +0100

Hi Fred,

Le 13/03/2015 17:43, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Friday, March 13, 2015
>>  9:32 AM To: Templin, Fred L; Mikael Abrahamsson Cc:
>>> following. It should be OK for a router to leave some of its
>>> links as link-local-only as long as the router has at least one
>>> GUA that it can use as the source address of any ICMPs it needs
>>> to send - right?
>>
>> And yes, it makes ok to talk about ll-only links on which
>> traceroute still works (even though it reports the GUA not the
>> LL).
>>
>> It would mean to ifconfig the same GUA on several of its
>> interfaces; if so the interface would no longer be LL-only,
>> although the other side of a link may be LL-only.  That link would
>>  be a link half-ll-only, or 'half-unnumbered' if I can say so.
>
> I am thinking of a router that pins a GUA on some sort of internal
> virtual interface (like a loopback) but leaves all of its other
> interfaces as link local only. Do you see a problem with that?

I don't see a problem with that.  These would be LL-only links, although
the Routers themselves have GUAs.  The routing would work.

I am not sure though what will be the src address of this
HOP_COUNT_EXCEEDED ICMP message - the GUA pinned on the virtual
interface?  Or the LL address on the real interface?

Alex

>>>> [mailto:[email-masked]] On Behalf Of Alexandru
>>>> Petrescu Sent: Friday, March 13, 2015 9:15 AM To: Mikael
>>>> Abrahamsson Cc: [email-masked] Subject: Re: [v6ops] Should we
>>>> use "unnumbered" in IPv6? - RFCs forbidding LL away
>>>>
>>>>>> For example RFC4291 "Addr Architecture" forbids packets
>>>>>> with src or dst address to get away from a link.  It
>>>>>> literraly says "Routers must not forward any packets with
>>>>>> Link-Local source or destination addresses to other
>>>>>> links."
>>>>>>
>>>>>> Whereas the dst part reads best, I wonder whether the src
>>>>>> part does not amount a bit to ingress filtering.  Ingress
>>>>>> filtering is a policy useful in some security context, but
>>>>>>  is also seen as a bad technique that needs to be overcome
>>>>>>  by some other technique. Ingress filtering would not be
>>>>>> There may be, in some context, a need of a packet with a
>>>>>> LL src address and a GUA dst address.  This packet would
>>>>>> be forwarded by routers, although they may log it as an
>>>>> Yes it should. RFC4291 says it MUST be dropped, with very
>>>>> good reason. We do not want LL (src or dst) packets being
>>>>> routed around.
>>>>
>>>> administrative allocation, and lack of same-scope equipotency,
>>>>  may induce harm when forwarding LL-src packets.
>>>>
>>>> Packets with src LL and dst GUA multiple hops away from that
>>>> link can be helpful to some applications not needing replies
>>>> (e.g. periodic beacons of routing protocols, or of tunnel
>>>> maintenance, or of NAT-state maintenance during traversal).
>>>>
>>>> I'd go as far as saying that packets with dst LL which is _one_
>>>> hop away should be forwarded, because the Router is able to
>>>> detect address collisions on both its links.  Beyond one hop it
>>>> would be a problem, but forwarding LL across one hop should not
>>>> break anything.
>>>>
>>>> Alex
>>>>
>>>>>
>>>>
>>>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Mar 2015 17:16:24 +0000

Hi Alex,

> Sent: Friday, March 13, 2015 9:52 AM

Would have to be the GUA, I guess. I think all of this is explained
in a source address selection document somewhere (someone
mentioned RFC6724) - I just wanted to be sure the use case was
not being deprecated.

Thanks - Fred

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Mar 2015 18:03:10 +0000

> have catastrophic consequences :

For sure, yes.  I'm just suggesting that 70 emails to discuss this topic so
far (13 emails in the original thread and 57 emails so far in this thread)
is bike-shedding.

Nick

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Mar 2015 12:30:30 -0700

> On Mar 13, 2015, at 04:33, Alexandru Petrescu <[email-masked]> wrote:
> 

You are stubbornly determined to ignore the facts of the situation. 

It is impossible to get ip6.arpa information for ULA or LL outside of a narrow administrative scope. Further, it is impossible to receive a hop-count-exceeded message from a non-adjacent router using a LL address. 

As such, scope very much matters. 

> as well.  And be ported back to IPv4 to report IPv4 LLs.

See above and multiple previous messages which have explained in detail why you are wrong about this. 

> It's unsafe to assume ff:fe and global prefix means SLAAC.

It's my device and I know that the address was generated using SLAAC. NO assumption involved, I configured it that way. 

> to DHCP, to sysadmins and to the random generation of privacy addresses.

I never said it was. 

> Except that traceroute does not tell for each tunnel its 4 addresses.

So what? It gives me enough information to identify the tunnel specifically. If I need more, I can find the tunnel configure with all four addresses using any one of the addresses. 

> You make a good supposition.  There is no guarantee but it's likely to be the case.  It's the same level of confidence in assuming 2a01:face:b00c:: belongs to facebook.  The scope does not matter, there is no difference between global or local scope.

Actually, I'm pretty confident that 2a01:face:b00c:: does not at all belong to Face Book. According to RIPE, that range is not assigned to anyone. 

Scope does matter. There is no reliable registry for LL or ULA. There is no guarantee of uniqueness for ULA and LL is virtually guaranteed to be duplicated elsewhere. 

On the other hand, I know with great certainty that 2620:0:930:: is DELONG and 2001:470:: is Hurricane Electric (or their customers). 

That's the whole point of GUA and the RIR system. 

> Do you mean that DNS requests are blocked if the parameter starts with "fe80"?

I mean that nobody at the root is going to delegate any portion of 0.e.8.f.ip6.arpa to you. 

Whatever you put in your server is meaningless outside of your zone of control unless it is delegated from the root. 

It really would be good if you made the effort to understand how DNS, trace route, ULA, and Link Local actually work before going another round in this conversation. It is clear from your statements that you have some incorrect assumptions at least. 

Owen

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Mar 2015 21:59:35 +0100

Hi,

On Fri, Mar 13, 2015 at 12:41:39PM +0100, Alexandru Petrescu wrote:
> Ok, but I will refrain from further commenting 

Very much appreciated.  Thanks.

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Mar 2015 15:20:27 -0700

> On Mar 13, 2015, at 04:53, Alexandru Petrescu <[email-masked]> wrote:
> 

Link local only seems a perfectly valid term. 

Such links should be discouraged if they handle non-local traffic, however. 

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Mar 2015 15:24:45 -0700

> On Mar 13, 2015, at 05:30, Alexandru Petrescu <[email-masked]> wrote:
> 

Nope. It is well considered architectural thinking. 

A packet which is global in scope should come from a host which can be reached globally and an address which has a valid global registration in an RIR database. 

> although they may log it as an exceptional case.  But it should not be

There is not. In fact, allowing such a thing is a terrible idea for many reasons which were discussed at length years ago. 

> chance of HOP_COUNT_EXCEEDED would report LLs as well.

While it would enable this particular possibility of dubious benefit at best, I would hold that possibility out as more of a reason not to do so than a reason to do so. 

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Mar 2015 15:27:56 -0700

Depends on your meaning of OK. 

It is technically permissible by the RFCs, but it's generally a bad idea as it creates ambiguities in diagnostic processes which are usually harmful. 

Unless you have some overriding benefit or reason for it, I think best practice is unique GUA per interface. 

Owen

> On Mar 13, 2015, at 09:22, Templin, Fred L <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Mar 2015 22:36:00 +0000

Hi Owen,

> From: Owen DeLong [mailto:[email-masked]]
> Sent: Friday, March 13, 2015 3:28 PM
> To: Templin, Fred L
> Cc: Alexandru Petrescu; Mikael Abrahamsson; [email-masked]

AERO is an example of a link-local-only link. IPv6 addresses and prefixes are assigned
*through* the link, and not *to* the link. Which should be fine as long as all AERO
routers have at least one GUA they can use for diagnostic purposes, right?

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 14 Mar 2015 06:21:35 +0100 (CET)

On Fri, 13 Mar 2015, Templin, Fred L wrote:

> AERO is an example of a link-local-only link. IPv6 addresses and 
> prefixes are assigned *through* the link, and not *to* the link. Which 
> should be fine as long as all AERO routers have at least one GUA they 
> can use for diagnostic purposes, right?

Yes. A router may use the weak host model to source packets with a 
loopback interface IP address that have a destination outside the directly 
connected interfaces which have LL only address.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 15 Mar 2015 23:06:37 +0000

>Of course traceroute can report them. They are just not very helpful.

If only routers and trace routes programs supported RFC5837... ;-)

-éric

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 15 Mar 2015 23:06:36 +0000

>local only. Do you see a problem with that?

See RFC 7404 (if not mistaken by the reference being off-line right now)

-éric

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 17 Mar 2015 00:54:41 +0000 (UTC)

So the reason I care about it and I think it is important to resolve is that the only significant reason I can think of to deploy link-local only links/interfaces is for security reasons. The address conservation reason to deploy unnumbered IPv4 links doesn't apply in IPv6.

If people are deploying link-local only links exclusively for security reasons, then I think it is important that the security properties of them are clear and obvious. Accurate naming of them, and having a different name to similarly configured links in IPv4 (because they are different), would help avoid the sorts of security issues that pop up when people put in place security measures that don't behave exactly how they expect.

Regards,
Mark.

________________________________
From: Nick Hilliard <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>; Gert Doering <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Saturday, 14 March 2015, 5:03
Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?

/ So the reason I care about it and I think it is important to resolve is that the only significant reason I can think of to deploy link-local only links/interfaces is for security reasons. The address conservation reason to deploy unnumbered IPv4 links doesn't apply in IPv6.

/ If people are deploying link-local only links exclusively for security reasons, then I think it is important that the security properties of them are clear and obvious. Accurate naming of them, and having a different name to similarly configured links in IPv4 (because they are different), would help avoid the sorts of security vulnerabilities that can occur when people put in place security measures that don't behave exactly how they expect.

/ Regards,
  Mark.

Nick

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Wed, 18 Mar 2015 02:21:07 -0600

They will need publicly routable numbers on a management network anyway,
most likely.  Private-use addresses are a horrible security mechanism
when you have firewalls and authentication to work with.

One reason I might do it is so that I don't have to request (and pay
fees for) additional allocations I don't really need.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Mar 2015 10:46:33 +0100

> They will need publicly routable numbers on a management network anyway,

These could be ULAs instead.  A network is presumably managed from 
within that network.

Alex

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 23 Mar 2015 08:23:25 -0400

Eric/All,

What about the term "administratively unnumbered?"  This could be 
defined as an interface where the network administrator did not 
specifically number the interface, but does not preclude it from having 
an address at all (i.e. LL address).

regards,

Victor K

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Mar 2015 07:33:33 -0500

On Mar 23, 2015, at 7:23 AM, Victor Kuarsingh <[email-masked]> wrote:
> What about the term "administratively unnumbered?"

That's a nice compromise, and also has the virtue of sounding good.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 23 Mar 2015 23:07:07 +0000 (UTC)

I still think 'link-local only' is better, as it is very explicitly saying what the addressing scheme is. There is no and cannot be any ambiguity. 
I think 'administratively unnumbered' is close to the inverse of that and less descriptive and specific.

      From: Victor Kuarsingh <[email-masked]>
 To: [email-masked] 
 Sent: Monday, 23 March 2015, 23:23
 Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?
   
Eric/All,

regards,

Victor K

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2015 23:56:46 +0000

Sorry, but “unnumbered” has already been Nacked by EricV and others in this mailer because the interface borrows the loopback interface’s ipv6 global address to source some ipv6 packets.
“Link-local only” doesn’t look good to me because what if the interface actually tried DHCPv6 or SLAAC for a GUA but DHCPv6 and SLAAC failed?   Thus “administratively” seems to be key so that one is clear the admin managing the interface on the node consciously wanted only a link-local address on the interface.  Why not

“administratively link-local only”.

Hemant

From: v6ops [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
Sent: Monday, March 23, 2015 7:07 PM
To: Victor Kuarsingh; [email-masked]
Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?

________________________________
From: Victor Kuarsingh <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Sent: Monday, 23 March 2015, 23:23
Subject: Re: [v6ops] Should we use "unnumbered" in IPv6?

Eric/All,

regards,

Victor K

On 2015-03-10 5:15 PM, Eric Vyncke (evyncke) wrote:
> On 10/03/15 15:52, "Philip Matthews" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Mar 2015 19:15:57 -0500

One cant have an interface be unnumbered yet numbered by a link-local 
address.

One can't have 'an interface with only link-local address' because there 
is the MAC address as well.

One cant have a '_link_ with only link local addresses' because a link 
is fixed into computers which have addresses configured on interfaces on 
that link, but also on virtual interfaces, and on other real interfaces. 
  A link by itself does not make much sense.

We could as well call this a 'transit-only' link.

Alex

Le 23/03/2015 18:56, Hemant Singh (shemant) a écrit :
> Sorry, but “unnumbered” has already been Nacked by EricV and others in
> this mailer because the interface borrows the loopback interface’s ipv6
> global address to source some ipv6 packets.
>
> “Link-local only” doesn’t look good to me because what if the interface
> actually tried DHCPv6 or SLAAC for a GUA but DHCPv6 and SLAAC failed?
> Thus “administratively” seems to be key so that one is clear the admin
> managing the interface on the node consciously wanted only a link-local
> address on the interface.  Why not
>
> *From:*v6ops [mailto:[email-masked]] *On Behalf Of *Mark ZZZ Smith
> *Sent:* Monday, March 23, 2015 7:07 PM
> *To:* Victor Kuarsingh; [email-masked]
> I still think 'link-local only' is better, as it is very explicitly
> saying what the addressing scheme is. There is no and cannot be any
> ambiguity.
>
> *From:*Victor Kuarsingh <[email-masked] <mailto:[email-masked]>>
> *To:* [email-masked] <mailto:[email-masked]>
> *Sent:* Monday, 23 March 2015, 23:23
>> On 10/03/15 15:52, "Philip Matthews" <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Mar 2015 18:43:30 -0500

> and less descriptive and specific.

+1

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 23 Mar 2015 21:32:45 -0400

All,

What's one more email in such an active conversation.  Here area few 
points to take note of.

- When I suggested "administratively unnumbered", I was intending to 
find text which has less imposed (vs just "unnumbered") meaning while 
attempting to keep within the spirit of the text in section 2.1.2.

- The intention of this text was to describe the configuration choices 
for links within a network, which was to apply a ULA/GUA or to not apply 
a ULA/GUA (in which case the LL address would be the only one that remains).

- The emphasis for the draft section is about what the 
operator/administrator will (or will not) apply as configuration and not 
what potential behaviors will be exhibited (although this would have 
relevance for troubleshooting, but I don't think that is specific to 
this draft in that it's something to consider more widely).

- The action in the one case (by the administrator) would be to not 
apply addressing (additional) to a link, in which case the result is 
LL-only.

- When I re-read the text to myself, substituting "administratively 
unnumbered" , it seemed to make sense to me (I am biased), and the flow 
of the text seems to make sense as I put myself into the position of a 
operator reading this for guidance. I don't think they will be confused 
at all (given the context and full text).

- Section 2.1.2 text does present the options as (a). link-local 
addresses ("unnumbered") or (b) have global or ULA addresses assigned. 
which are in fact the choices (where I am already presuming we would 
have replaced "unnumbered" with "administratively unnumbered")

- I think it's important for us to realize the intention of the section, 
and what we are trying to accomplish by providing the general choices to 
the reader.

- We then have a reference to "draft-ietf-opsec-lla-only" which is a 
document that then goes into more detail of the approach, advantages and 
caveats of using LL-only addressing models.

I don't want to undermine the great conversation we had on the list on 
the potential impacts of using ll-only and the behaviors which we may 
see, but feel that (as I think others have noted), can be captured in a 
more appropriate document.

my two cents,

regards,

Victor K

On 2015-03-23 8:15 PM, Alexandru Petrescu wrote:
> One can't have 'an interface with only link-local address' because 
> there is the MAC address as well.
>
> is fixed into computers which have addresses configured on interfaces 
> on that link, but also on virtual interfaces, and on other real 
> interfaces.  A link by itself does not make much sense.
>
>>> On 10/03/15 15:52, "Philip Matthews" <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> terms
>>>> that
>>>> should

---

From: "Metzler, Dan J" <[email-masked]>
Date: Tue, 24 Mar 2015 13:52:43 +0000

Hi,

See below:

> From: v6ops [mailto:[email-masked]] On Behalf Of Victor Kuarsingh
> Sent: Monday, March 23, 2015 8:33 PM
> To: Alexandru Petrescu; [email-masked]
> What's one more email in such an active conversation.  Here area few points
> to take note of.
> 
> - When I suggested "administratively unnumbered", I was intending to find
> text which has less imposed (vs just "unnumbered") meaning while attempting
> to keep within the spirit of the text in section 2.1.2.

I sort of understand where you're coming from, but  I think the addition of "administratively" just modified the confusion, but did not remove it.
I think you're trying to equate the situation to something in IPv4 to make it seem more familiar.  In the short term that might have some benefit, but in the long term it seems to lose meaning.
I think the term "unnumbered" is what introduces the confusion, simply because it is different with IPv6.

> 
> - The intention of this text was to describe the configuration choices for links
> within a network, which was to apply a ULA/GUA or to not apply a ULA/GUA
> (in which case the LL address would be the only one that remains).

If you are using "administratively unnumbered" in any way that is not intended to confuse the issue, then I think you can't assume that LL is the only one that remains.  With IPv6, that just means you're leaving it up to the network operator vs the system admin.  It might be ULA.  It might be GUA.  It might be LL.  It depends on what's in the flags in the RA.
If that's really what you meant then the assumption that LL address is the only one that remains is simply a flawed assumption, but "Administratively Unnumbered" becomes closer to a reasonable term, other than the fact that "unnumbered" is technically inaccurate.  (And that's probably what people find most confusing.)
If you really meant LL-only, then "Administratively Unnumbered" is probably not the best term because it doesn't really describe what you meant.

(Do you see how it gets confusing?)

> 
> - The emphasis for the draft section is about what the operator/administrator
> will (or will not) apply as configuration and not what potential behaviors will
> be exhibited (although this would have relevance for troubleshooting, but I
> don't think that is specific to this draft in that it's something to consider more
> widely).

Agreed.

> 
> - The action in the one case (by the administrator) would be to not apply
> addressing (additional) to a link, in which case the result is LL-only.

What do you mean by "administrator"?  (System admin or network admin or both)
That's only correct if there is no router on the network, but if that's part of the scenario you're discussing right now, then ok.  (Can also get GUA and ULA from RAs imposed by the network operator; unless by the phrase "by the administrator" you meant by either network or system admin. )

Ultimately, if you really mean LL-only, I think you should just say that.  It seems like a lot of effort to dance around it with implications, and still try to convey what you actually meant without confusing the issue.

Cheers,

- Dan Metzler

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Mar 2015 14:56:24 +0100

+1

[email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 24 Mar 2015 15:06:52 +0100 (CET)

> I think 'administratively unnumbered' is close to the inverse of that and less descriptive and specific.

Yes, I don't like "administratively unnumbered" either. "interface without 
address", "link-local only" or some other variant is fine, but I really do 
not like the use of "unnumbered", with or without prefix to this.

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 24 Mar 2015 10:39:45 -0400

> I think the term "unnumbered" is what introduces the confusion, simply because it is different with IPv6.
I totally understand the differences between IPv4 and IPv6.  You are 
right in a way, in that there are some parallels between IPv4 and IPv6 
being drawn (since some parallels still exist, as well as differences).

I guess the parallel component is the action the administrator (some may 
call this the sysadmin, or the network admin - all the same to me - the 
person or tool configuring stuff) takes.  The result is where one of the 
differences are between IPv4 and IPv6.
> If you are using "administratively unnumbered" in any way that is not intended to confuse the issue, then I think you can't assume that LL is the only one that remains.  With IPv6, that just means you're leaving it up to the network operator vs the system admin.
Maybe I missed something here, but we are specifically talking about the 
network operator / system admin (the subject of the conversation is the 
actions the person designing (and/or configuration) the network makes.

> It might be ULA.  It might be GUA.  It might be LL.
I think this is true and I think this is clear in the text as well.
>   It depends on what's in the flags in the RA.
This is true, and using an RA to get a ULA/GUA onto an interface (vs. 
manual configuration) is just a way to do it (I don't think our draft 
discusses or recommends on how to accomplish the addressing.

We point documents like RFC4852 which expand on the methods on how to 
address stuff (as an example).
> If that's really what you meant then the assumption that LL address is the only one that remains is simply a flawed assumption, but "Administratively Unnumbered" becomes closer to a reasonable term…
I think we are all open to new terms, but that would likely become 
subject to further misconceptions unless well defined.  I guess the 
"adminstatively" part of hte term was to denote "something you do to 
give it an address".

> (Do you see how it gets confusing?)
Well I do understand people's point, irrespective if I agree. To be 
honest, I am not confused, and when reading the text (as I had noted 
before) I don't think folks who would seek guidance in such a draft 
would come away not understanding what the options are, or what the 
result will be.

I do agree, that out of context, it can be considered confusing, but I 
am not considering the use of the word out of context.

> What do you mean by "administrator"?  (System admin or network admin or both)
The term administrator was to apply to anyone who managers/configures 
network (was to cover all cases).  A sysadmin and netadmin are just 
types of administrators.

Victor K

---

From: Philip Matthews <[email-masked]>
Date: Tue, 24 Mar 2015 14:17:45 -0400

Just a heads up to everyone that Victor and I have a presentation slot tomorrow for the Design Choices draft, and we plan to have a discussion on what term the WG would like us to use here.

Philip

On 2015-03-24, at 10:39 , Victor Kuarsingh wrote:

> I totally understand the differences between IPv4 and IPv6.  You are right in a way, in that there are some parallels between IPv4 and IPv6 being drawn (since some parallels still exist, as well as differences).
> 
> I guess the parallel component is the action the administrator (some may call this the sysadmin, or the network admin - all the same to me - the person or tool configuring stuff) takes.  The result is where one of the differences are between IPv4 and IPv6.
> Maybe I missed something here, but we are specifically talking about the network operator / system admin (the subject of the conversation is the actions the person designing (and/or configuration) the network makes.
> 
> This is true, and using an RA to get a ULA/GUA onto an interface (vs. manual configuration) is just a way to do it (I don't think our draft discusses or recommends on how to accomplish the addressing.
> 
> We point documents like RFC4852 which expand on the methods on how to address stuff (as an example).
> I think we are all open to new terms, but that would likely become subject to further misconceptions unless well defined.  I guess the "adminstatively" part of hte term was to denote "something you do to give it an address".
> 
> Well I do understand people's point, irrespective if I agree. To be honest, I am not confused, and when reading the text (as I had noted before) I don't think folks who would seek guidance in such a draft would come away not understanding what the options are, or what the result will be.
> 
> I do agree, that out of context, it can be considered confusing, but I am not considering the use of the word out of context.
> 
> The term administrator was to apply to anyone who managers/configures network (was to cover all cases).  A sysadmin and netadmin are just types of administrators.
> 
> Victor K
> 
>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 25 Mar 2015 10:07:25 -0700

+1

I dislike administratively unnumbered for the reasons stated.

Owen

> On Mar 23, 2015, at 16:07 , Mark ZZZ Smith <[email-masked]> wrote:
>

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 25 Mar 2015 18:23:20 +0100

I don't want to bikeshed, but as this is not dying down:

Please consider everything Mark said in this thread +1 by me.

Until I pipe up, this is a standing +1 for everything he will say.

Lurking,
Richard

Sent by mobile; excuse my brevity.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Mar 2015 12:39:17 -0500

> Until I pipe up, this is a standing +1 for everything he will say.

So you are saying that Mark should be considered to have two votes?

:)

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 25 Mar 2015 21:48:27 +0100

> So you are saying that Mark should be considered to have two votes?

May he hum louder.

Richard

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Mar 2015 15:54:15 -0500

> May he hum louder.

That's actually specifically discussed in RFC 7282!   :)

---

From: Tore Anderson <[email-masked]>
Date: Thu, 26 Mar 2015 08:56:44 +0100

* Philip Matthews <[email-masked]>

> it acceptable to mix the two sets of terms?

I didn't quite catch on the Meetecho if a final decision was reached
yesterday, but in case not here's my suggestions:

- Link-scoped (IPv6) interface

vs

- Global-scoped (IPv6) interface

The global scope includes the link scope, so the latter wouldn't mean
"no link local address".

(Or maybe it's better to say "globally" and "scope", my English isn't
good enough to know which of these nuances would be 100% correct.)

Tore
who finally succumbed to the bikeshedding temptation

---

From: "Howard, Lee" <[email-masked]>
Date: Thu, 26 Mar 2015 08:03:52 -0400

We seemed to have rough consensus on link-local-address-only.

Lee

>who finally succumbed to the bikeshedding temptation

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Mar 2015 13:53:23 +0000

> We seemed to have rough consensus on link-local-address-only.

The consensus alternative I recall seeing was "link-local-only" (three
words separated by two dashes).

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Howard, Lee
> Sent: Thursday, March 26, 2015 5:04 AM
> To: Tore Anderson; Philip Matthews
> Cc: v6ops list
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is
> addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying,
> or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have
> received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and
> any printout.
>

---

From: Jen Linkova <[email-masked]>
Date: Thu, 26 Mar 2015 15:50:46 +0100

> words separated by two dashes).

IMHO (but I'm not a native speaker), "link-local-only interface"
sounds weird. Interface isn't link-local,
it is address it has is link-local.
So maybe we should use 'LLA-only interface' (less dashes ;)) and
'GUAed interface' for an interface with a global unicast address
assigned?

-- 
SY, Jen Linkova aka Furry

---

From: Owen DeLong <[email-masked]>
Date: Thu, 26 Mar 2015 11:21:34 -0700

> On Mar 26, 2015, at 00:56 , Tore Anderson <[email-masked]> wrote:
> 

Gramatically, I think you’re looking for globally-scoped.

I question the value of applying these terms to interfaces as they really apply to the address, not the interface.

Owen

---

From: "Howard, Lee" <[email-masked]>
Date: Thu, 26 Mar 2015 14:35:53 -0400

>words separated by two dashes).

You're right. I abbreviated to LLA-only in my notes, but these were the
options in Philip's slides:
1.³unnumbered interface²
2.³link-local-only interface²
3.³administratively unnumbered interface²
4.³locally-numbered interface²
5.³link-numbered interface²
6.³administratively link-local only interface²

I heard many people say, "Number two."

Lee

>> This E-mail and any of its attachments may contain Time Warner Cable
>>proprietary information, which is privileged, confidential, or
>> subject to copyright belonging to Time Warner Cable. This E-mail is
>>intended solely for the use of the individual or entity to which it is
>> addressed. If you are not the intended recipient of this E-mail, you
>>are hereby notified that any dissemination, distribution, copying,
>> or action taken in relation to the contents of and attachments to this
>>E-mail is strictly prohibited and may be unlawful. If you have
>> received this E-mail in error, please notify the sender immediately and
>>permanently delete the original and any copy of this E-mail and
>> any printout.
>>

---

From: Owen DeLong <[email-masked]>
Date: Thu, 26 Mar 2015 11:53:46 -0700

Limited to those choices, I would pick number 2 as well. However, as stated previously, I prefer to remove the word interface as it really isn’t applicable.

Owen

> On Mar 26, 2015, at 11:35 , Howard, Lee <[email-masked]> wrote:
> 
> 
> 
> On 3/26/15, 8:53 AM, "Templin, Fred L" <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 26 Mar 2015 18:07:47 -0400

Indeed, there seemed to be a strong consensus for #2 in the WG session yesterday.

To address Owen's comment, our (the authors) intention was to have an adjective phrase that could be applied to an interface or a link. As in "Interface X is a link-local-only interface" or  "Would you shutdown the link-local-only interface?".

The only problem is that I don't know what phrase we are going to use for the converse. The draft currently talks about "numbered" vs "unnumbered" interfaces -- if I replace the latter with "link-local-only" then I am unsure what to use for the former.  Sigh ...

Philip

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2015 17:11:02 -0500

Le 26/03/2015 17:07, Philip Matthews a écrit :
> To address Owen's comment, our (the authors) intention was to have an
> adjective phrase that could be applied to an interface or a link. As in
> "Interface X is a link-local-only interface" or  "Would you shutdown the
> link-local-only interface?".

One can't say an interface is a link-local-only interface because 
there's at least the MAC address on it as well.

You could say: don't ever shutdown the interface which doesnt have a 
global address on it, because it has at least one link-local address on it.

Alex

>
> The only problem is that I don't know what phrase we are going to use
> for the converse. The draft currently talks about "numbered" vs
> "unnumbered" interfaces -- if I replace the latter with
> "link-local-only" then I am unsure what to use for the former.  Sigh ...
>
> Philip
>
>> Limited to those choices, I would pick number 2 as well. However, as
>> stated previously, I prefer to remove the word interface as it really
>> isn’t applicable.
>>
>> Owen
>>
>>> On Mar 26, 2015, at 11:35 , Howard, Lee <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>
>>>
>>> On 3/26/15, 8:53 AM, "Templin, Fred L" <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> [email-masked] <mailto:[email-masked]>
>>>>
>>>>> On 3/26/15, 2:56 AM, "Tore Anderson" <[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>>
>>>>>> * Philip Matthews <[email-masked]
>>>>>> <mailto:[email-masked]>>
>>>>>>
>>> intended solely for the use of the individual or entity to which it
>>> is addressed. If you are not the intended recipient of this E-mail,
>>> you are hereby notified that any dissemination, distribution,
>>> copying, or action taken in relation to the contents of and
>>> attachments to this E-mail is strictly prohibited and may be
>>> unlawful. If you have received this E-mail in error, please notify
>>> the sender immediately and permanently delete the original and any
>>> copy of this E-mail and any printout.
>>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 26 Mar 2015 23:58:34 +0100 (CET)

> there's at least the MAC address on it as well.

MAC address is at L2, we're talking L3 here.