Subject: router vs. host discussion in 6man today for the /127 draft

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 24 Mar 2010 17:47:09 -0500

Hey folks,

It's not that an IPv6 home router has one WAN interface acting as a
router while another interface on the home router is a host.   The
problem is also not about a home router or a router sitting in the
Internet core or the WAN.   Any router has one or more network
interfaces over which the router performs routing.   But when the
network interface is acquiring an IPv6 address, it is then the interface
is acting as a host.  Sorry, I didn't read the
draft-kohno-ipv6-prefixlen-p2p-01.txt yet but the concept seems fine to
me to use a /127.  We may have to make sure the language in the document
is tight because IPv6 has so many restrictions like a /64 prefix length
for SLAAC addresses and the like.

Hemant

Hemant Singh
Technical Leader.engineering
Product Development
[email-masked]
Phone: +1 978 936 1622
Cisco Systems, Inc.
United States
Cisco.com - http://www.cisco.com

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Mark Smith <[email-masked]>
Date: Thu, 25 Mar 2010 20:23:07 +1030

On Wed, 24 Mar 2010 17:47:09 -0500

> for SLAAC addresses and the like.

I have read it, and unfortunately I don't think it provides any
compelling arguments for /127s at all.

I'll state up front that I'm in the /64 camp for everything, because I
like the simplicity of it, with simpler usually meaning cheaper to
operate and less prone to error. I am willing to be convinced that
other prefix lengths should be supported, however it'll need to either
be significantly cheaper than the value in simplicity of
universal /64s, or something that can't be done equivalently with /64s.
I haven't found anything that meets either of those criteria.

"4.  Problems identified with 127-bit prefix lengths in the past

   [RFC3627] discourages the use of 127-bit prefix lengths due to
   conflicts with the Subnet-Router anycast addresses.  However, the RFC
   also states that the utility of Subnet-Router Anycast for
   point-to-Problems identified with 127-bit prefix lengths in the past"

This section does not fully summarise the all the arguments for
avoiding /127s in RFC3627. RFC3627 makes two arguments - specifically
against /127s, as well as against using any prefix lengths longer
than /64s e.g.

"5.  Other Problems with Long Prefixes

   These issues are not specific to /127.

   One should note that [ADDRARCH] specifies universal/local bits (u/g),
   which are the 70th and 71st bits in any address from non-000/3 range.
   When assigning prefixes longer than 64 bits, these should be taken
   into consideration; in almost every case, u should be 0, as the last
   64 bits of a long prefix is very rarely unique.  'G' is still
   unspecified, but defaults to zero.  Thus, all prefixes with u or g=1
   should be avoided."

If the purpose of the draft-kohno-ipv6-prefixlen-p2p-01.txt draft is to
contradict the position of RFC3627, then I think the draft needs to
address all the points made in RFC3627, not just the Anycast
router one. That would fundamentally mean changing the updated
version of RFC3513, RFC4291, "IP Version 6 Addressing Architecture" to
support interface identifiers that are smaller than 64 bits.

"5.1.  Ping-pong issue

  As described in [PINGPONG], a forwarding loop may occur on a point-
   to-point link with a prefix length shorter than 127.  This does not
   affect interfaces that perform Neighbor Discovery, but some point-to-
   point links, such as SONET, do not use Neighbor Discovery.  As a
   consequence, configuring any prefix length other than 127 bits on
   these links creates an attack vector in the network."

I'd like to understand why SONET links don't use ND. Are there any
references to operating IPv6 over SONET that explain why ND can't be
enabled?

"5.2.  Neighbor Cache Exhaustion issue

   As described in Section 4.3.2 of [RFC3756], the use of a 64-bit
   prefix length on an inter-router link that uses Neighbor Discovery
   (e.g., Ethernet) potentially allows for denial-of-service attacks on
   the routers on the link.

   Consider an Ethernet link between two routers A and B to which a /64
   subnet has been assigned.  A packet sent to any address on the /64
   (except the addresses of A and B) will cause the router attempting to
   forward it to create an new cache entry in state INCOMPLETE, send a
   Neighbor Solicitation message to be sent on the link, start a
   retransmit timer, and so on [RFC4861]."

There is no denying this is an issue. However, it is not unique to
point-to-point links - a router attached to an edge /64 LAN segment with
downstream PCs is just as vulnerable. Proportionally, there are
usually at least equal and commonly far more LAN segments in most
networks than there are point-to-point links. Adopting /127s for
point-to-points will mitigate this problem for them, however you're
still vulnerable for all your LAN segments. I think LAN segments might
be a more entertaining target for this DoS attack - not only do you
clog up the router's ND cache with unresolved entries, you also create
large amounts of multicast NS traffic on the attached LAN, possibly
flooded out all downstream switch ports, and creating processing load on
downstream PCs who's addresses match solicited node multicast addresses.

That is an argument for supporting longer than /64s on LAN segments
too. However then we loose the advantage of using EUI64s as IIDs, other
useful mechanisms like CGAs, SLAAC etc.

I think this problem needs to be fixed in Neighbor Discovery.
One possible way would be to make Neighbor Discovery
stateless by using the flow label field in a NS/NA transaction carry a
transaction cookie, such that the router can verify it issued the
trigger NS without having to remember any state for it while it is
outstanding. 

"5.3.  Other reasons

   1.  With the use of 127-bit or other long prefix lengths, interface
       IDs are simpler and easier to remember (e.g., the Interface ID is
       0 or 1)."

::1/64 and ::2/64 are just as simple (arguably even more so - most
people don't start counting at 0), plus you don't have to remember that
you've got at least two different prefix lengths on your network.
You're also not going to have to worry about the values of the 70th and
71st bits, as they'll be set correctly. In my opinion, that
makes ::1/64 and ::2/64 significantly simpler than ::0/127 and ::1/127.

"2.  Using 64-bit prefixes for inter-router links leaves a large
       number of unused addresses that an attacker with physical access
       to a link could use to insert a node onto the link without having
       to compromise the routing protocols used on the link.  If 127-bit
       prefix lengths are in use, this is not possible."

People are enabling authentication in routing protocols to protect
against this. It also protects against somebody attaching to the link
and spoofing one of the legitimate routers' source addresses, and
sending a bogus routing update. If there is a flaw in a router allowing
to send a spoofed offlink routing update, authentication protects
against that too.

"3.  Though address space conservation considerations are less
    important for IPv6 than they are in IPv4, it may still be
    desirable to use the smallest possible prefix to number links
    (and thus use, for example, /127 for point-to-point links).  For
    example, a large end-site that is assigned a /48 of IPv6 space
    may not want to reserve a full /64 for every point-to-point link
    to avoid renumbering in the future."

So you've got your /48, with 65 536 subnets, and instead of allocating
16 384 /64s for point-to-points links (of which you'll never be ever
likely to have), leaving 49 152 /64s for LAN segments (of which you'll
never be every likely to have), you make your life harder by choosing
different prefix lengths, remembering to manage the 70/71 bit
issue, saving 16 383 /64s for your up to 65 535 LAN segments (of which
you'll never ever be likely to have)? If you are one of the rare
organisations who will have a network that large, you'll be getting
bigger than a /48 anyway. I don't think renumbering due to a lack of
address space needs to be much of a consideration in IPv6 addressing.

As I said at the outset, I'm willing to be convinced that there are
reasons to have longer than /64s. I just don't find any of the above
arguments compelling.

Regards,
Mark.

---

From: [email-masked]
Date: Thu, 25 Mar 2010 11:13:09 +0100 (CET)

> references to operating IPv6 over SONET that explain why ND can't be

A SONET/SDH link is a real point to point link. Which means that in
principle you can use totally unrelated addresses at each end of the
link. There is no need for an address resolution protocol (ND/ARP)
because you simply stuff the packet into one end of the point to point
link and it comes out at the other end.

Unrelated addresses at each end is sometimes used in practice. Nowadays
it is more common to simply use a /30 or /31 (IPv4) or /126 (IPv6) to
get a "subnet" which encompasses both ends.

*Requiring* ND would preclude the use of completely unrelated addresses
at each end, wouldn't it?

Steinar Haug, Nethelp consulting, [email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 25 Mar 2010 09:26:57 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Thursday, March 25, 2010 3:13 AM
>To: [email-masked]
>Cc: Hemant Singh (shemant); [email-masked]; [email-masked];
[email-masked]; [email-masked]
>Subject: Re: router vs. host discussion in 6man today for the /127
draft

>link and it comes out at the other end.

So what!  A point to point link is so not a justification to not use ND
on the link.  PPP for IPv6 is a also a point to point link that does use
ND (with no DAD) and 64-bit interface ids - see RFC 5072.

Hemant

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 25 Mar 2010 12:43:18 -0500

You can use unrelated addresses at each end if you use RA w/PIO's to
inject on-link prefixes in the Prefix Lists on both routers. 

Thanks,
- Wes

Wes Beebee
Software Engineer
Product Development
[email-masked]

United States

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, March 25, 2010 6:13 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: router vs. host discussion in 6man today for the /127 draft

Steinar Haug, Nethelp consulting, [email-masked]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 Mar 2010 12:00:58 -0700

>   unspecified, but defaults to zero.  Thus, all prefixes with u or g=1

Is it enough to say in the draft that the u/g bit should be set to zero when
the operator assigns /127 prefixes?

> support interface identifiers that are smaller than 64 bits.

That's why the draft updates RFC 4291. Is this not sufficient?

"5.1.  Ping-pong issue
> references to operating IPv6 over SONET that explain why ND can't be

I don't know. It's possibly just not implemented because in general it's not
very useful to do neighbor discovery on a link that can only have one other
host on it. Maz, can you comment here?

> still vulnerable for all your LAN segments.

Correct. However, as the draft says, the operational impact of taking out a
large (e.g., 80 Gbps aggregate) backbone link or inter-operator peering link
using something like this is vastly superior to the impact of a DoS attack
on one LAN, which typically has lower-speed links.

> against this.

No - as the draft says, you cannot protect against this by enabling
authentication in routing protocols. If you assign a /64 to a link and
someone inserts host(s) onto the link, the hosts will be able to send and
receive packets regardless of routing protocol authentication, since the
routers are already configured to route the whole /64 to the link. Doing
this on a /127 link will require taking the address belonging to one of the
two routers (e.g., by triggering DAD, or MAC address spoofing) which will
immediately be visible to the operator

> never be every likely to have),

Really? It seems to me that depending on how you design your network, you
might have as many as one or two point-to-point links for each LAN, because
you need to number the uplinks of the routers that provide service to the
LANs. So you'd end up dedicating 50% or 66% of your address space to P2P
links. Seems like a waste to me, and if the argument is "640k should be
enough for everybody", well... we know how it went with IPv4.

Cheers,
Lorenzo

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Mar 2010 07:36:32 +1030

Hi Lorenzo,

On Thu, 25 Mar 2010 12:00:58 -0700

> the operator assigns /127 prefixes?

If it was "must set", it would be. 

> That's why the draft updates RFC 4291. Is this not sufficient?

I don't see anywhere it specifically says RFC4291 is to be updated, or
replacement text for the impacted section(s).

> on one LAN, which typically has lower-speed links.

The thing is, these types of attacks aren't going to stop even if you
protect your p2p links using this method. There would still be many
vulnerable parts, which could also be hosting content just as important
as your 80Gbps backbone link. Imagine high profile content
provider sharing a /64 across a cluster of hosts acting as a front end
for a search engine.

> immediately be visible to the operator

Well then I think this is an unauthorised link layer access problem.
Your LAN segments are far more vulnerable - there are points of
attachment to them at every staff member's desk.

point to point links between routers are typically in physically
secured infrastructure or facilities. If you're still worried about
those point to point links being vulnerable to this attack, then you're
probably willing to put up with the overheads of enabling IPsec or if
it's available, linksec.

> enough for everybody", well... we know how it went with IPv4.

You're right, "it depends". The draft doesn't say this advice
depends on the network scenario and design. My example is of what I
think will be the common case. Most corporate networks, the most common
large networks, have ratios of more LANs to WANs/point-to-point links.
As this section isn't specific about scenarios, I think it is making a
general recommendation that applies to the most common cases, and I
disagree with it as a general recommendation because you're
unnecessarily saving a lot of what you have an "excess" off, at the
cost of simplicity.

>Seems like a waste to me, and if the argument is "640k should be

Waste is something you get nothing for. If you use address space to get
simplicity and operational convenience, you're not wasting addresses.
We love the simplicity and convenience of Ethernet addresses because
they're plug-and-play, and they can be because they're larger than they
operationally need to be.

The 640K thing is an interesting one. IIRC (from some history books,
I'm not quite old enough to have known these details) the very first IBM
PC had 16KB of RAM. The 8086 had a maximum memory size of 1MB. The ROM
BIOS in the PC was so limited that IBM knew that add-in devices would
be adding in BIOS code, so they reserved a relatively large amount of
address space out of that 1MB, leaving 640K for RAM. Reserving 640KB
when you're shipping with 16KB? That statement, "640k should be enough
for everybody", starts to sound quite reasonable in that context.

IPv4 was the same I think. If you dig into the pre-RFC791 versions of
the IP protocol e.g. RFC760 and earlier IENs, they only allowed a
single network octet i.e. all addressing was "class A". So for quite a
number of years, there was an expectation of no more than 256 networks
in the Internet.

I think both of these are examples of completely unexpected and wild
success. I think in IPv6 that has been learned from, which is why the
default allocation of a /48 of subnets is so "large" - they want to
make sure address space is something that isn't a constraint for most
people to increase the size of their network.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Mar 2010 10:25:42 +1300

> the operator assigns /127 prefixes?

s/should/MUST/. And IMHO that alone is sufficient reason to progress
this draft. Operators already use /127 prefixes for router/router links,
they will continue to do so whatever the IETF writes, but they would
likely respect this rule if it was documented.

Yes, this is an exception to the general rule, but if point-to-point
links between routers aren't a special case, I don't know what is.

I don't think we need to justify obsoleting an informational
RFC in the face of reality. Just make this a short BCP, with
most of the words removed.

Alternatively, we could continue to ignore the real world.

  Brian
> ------------------------------------------------------------------------
>

---

From: Jared Mauch <[email-masked]>
Date: Thu, 25 Mar 2010 17:30:45 -0400

> most of the words removed.

+1

---

From: Mark Smith <[email-masked]>
Date: Fri, 26 Mar 2010 08:14:45 +1030

On Fri, 26 Mar 2010 10:25:42 +1300

> Alternatively, we could continue to ignore the real world.

Well, I live in that operator world too. Just because things have been
done in the past incorrectly doesn't justify making it acceptable. They
can be considered as "IPv4 thinking" aberrations.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 25 Mar 2010 17:49:15 -0400

> can be considered as "IPv4 thinking" aberrations.

There's lots of "real world" networking practices that I consider harmful, bad, should be banned and prosecuted with being forced to sit behind a 2400bps CSLIP connection, et al, but /127s certainly don't fall into that category.

- Jared

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 Mar 2010 17:59:20 -0700

> replacement text for the impacted section(s).

The header says "updates 4291". But yes, there is no text that says what
exactly should be updated.

> provider sharing a /64 across a cluster of hosts acting as a front end

As you might be able to see from my affiliation, I am familiar with the
network designs used in large content providers have large-scale IPv6
deployments today. The problem of LAN links can be solved in other ways.

Absolutely - but /127 will provide some protection against that too.

> attachment to them at every staff member's desk.

Yes, but the damage is more contained and enterprise networks tend to be
protected by edge filters.

> probably willing to put up with the overheads of enabling IPsec or if

Not necessarily. I am, however, willing to use /127 on routers, because it
works today and provides all these benefits, with the only downside being
that it doesn't conform to RFC 3627. The running code is there. If there's
rough consensus, then we should go ahead.

---

From: Miya Kohno <[email-masked]>
Date: Sat, 27 Mar 2010 00:14:25 +0800

Hi Mark and all,

Thank you for your reviewing the draft and the valuable discussion. 

> If the purpose of the draft-kohno-ipv6-prefixlen-p2p-01.txt 
> draft is to contradict the position of RFC3627, then I think 
> the draft needs to address all the points made in RFC3627, 
> not just the Anycast router one. That would fundamentally 
> mean changing the updated version of RFC3513, RFC4291, "IP 
> Version 6 Addressing Architecture" to support interface 
> identifiers that are smaller than 64 bits.

RFC3627 admits the use of other longer prefixes e.g. /112, /120, /126.
And this draft basically adheres to RFC3627. The difference is that the
use of /127 prefix length is no longer be considered as harmful. (This
was stated in the -00 draft. Maybe we should put this back.)

The problem is the title of the RFC3627... Only because of the title, it
is said that /127 is prohibited by IETF. So we wanted to invalidate
this. 

But "obsoletes" might be too strong. Would "updates" be more
adequate...?

> I'd like to understand why SONET links don't use ND. Are 
> there any references to operating IPv6 over SONET that 
> explain why ND can't be enabled?

ND is a great mechanism for plug and play. But inter-router p2p link
does not require it and it's simpler to turn it off if unnecessary. 

Please note that the scope of the draft is limited to "inter-router p2p
links". So it excludes LAN segments, hosts which need SLAAC, etc. We'd
clarify this more in the next version.

And for LAN segments, I agree ND should be enhanced for solving the ND
cache issue.

Thanks,
Miya

---

From: Shin Miyakawa <[email-masked]>
Date: Sat, 27 Mar 2010 01:33:37 +0900 (JST)

Kohno-san,

> And for LAN segments, I agree ND should be enhanced for solving the ND

How about inter-router ethernet links  today we often use ?
We'd like to know about your opinion.

Shin Miyakawa/ NTT Communications

---

From: Randy Bush <[email-masked]>
Date: Fri, 26 Mar 2010 10:11:20 -0700

>> links".

which may be a bit restrictive.  i occasionally have p2p inter-server
links on which i use a /127.

> How about inter-router ethernet links today we often use ?

/127 is what we use.

randy

---

From: Shin Miyakawa <[email-masked]>
Date: Sat, 27 Mar 2010 02:29:12 +0900 (JST)

Randy,

Thank you very much for your clear answer :-)

>> How about inter-router ethernet links today we often use ?

It sounds to me that you IIJ are using ethernet link as just p2p link
and ask your customer use just like you. I see.

Then, still I'd like know about the case if inter-router ethernet link 
with more than two routers just like some Internet Exchange,
some  enterprise backbone or so, for example.

What is your (or Miya-san's) recommendation ?

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Sat, 27 Mar 2010 02:43:39 +0900 (JST)

Randy,

>> with more than two routers just like some Internet Exchange, some
>> enterprise backbone or so, for example.
> 
> that is not a p2p link.  the draft is about p2p links.

oh. OK. I understand that your point. Thanks.

Shin

---

From: Randy Bush <[email-masked]>
Date: Fri, 26 Mar 2010 10:36:44 -0700

randy

---

From: Miya Kohno <[email-masked]>
Date: Sat, 27 Mar 2010 01:49:05 +0800

Shin-san,

> Then, still I'd like know about the case if inter-router 
> ethernet link with more than two routers just like some 
> Internet Exchange, some  enterprise backbone or so, for example.

I'd say an adequate prefix length can be chosen based on operators
policy. (/64, /112, etc.)
But as for the draft, "more than two routers" is out of the scope of the
document.

Miya

---

From: Shin Miyakawa <[email-masked]>
Date: Sat, 27 Mar 2010 03:10:32 +0900 (JST)

Miya-san,

I understand that the draft is just for p2p. OK. It's just fine with me.

Actually, the text you wrote

> And for LAN segments, I agree ND should be enhanced for solving the ND

caused my question 

 How about inter-router ethernet links (with 3+ routers) today we often use ?

It seems to me that if we have solutions for the case of 
inter-router ethernet links with more than three routers against
the problems you mentioned in the draft, 
they also could be appicable for inter-router ethernet liks 
with only two routers, I think.

# Then, what happend if we can not have solutions for 3+ more routers case ??? 

But it is ok, if you do not need to answer to this, just because the draft
is just for p2p case as you and Randy told. Sure.

Of course, if you let me know about your opinion, I really appreciate it.

Best wishes,

Shin Miyakawa

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Mar 2010 15:42:21 -0700

> But as for the draft, "more than two routers" is out of the scope of the

Agreed. I think the draft is explicitly not attempting to address this
question because there is no agreement on this even among the authors. :-)

---

From: Miya Kohno <[email-masked]>
Date: Sat, 27 Mar 2010 21:35:23 +0800

Shin-san,

> > And for LAN segments, I agree ND should be enhanced for 
> > solving the ND cache issue.
> 
> caused my question 
> 
> inter-router ethernet links with more than three routers 
> against the problems you mentioned in the draft, they also 
> could be appicable for inter-router ethernet liks with only 
> two routers, I think.
> 

I think there is no generalized answer. It all depends.

 - If it's a typical LAN segment where plug and play is given, 
     Then /64 of course (+ enhanced ND, hopefully)

 - If it's an inter-router link where plug'n play is not required, and
the number of routers are limited and deterministic, 
     Then appropriate prefix-length (e.g. > /112) can be chosen. It
could mitigate the problems to a certain extent. (But not perfectly,
unlike /127... So one might think the merit does not overweigh the
advantage of uniformed /64.)

Cheers,
Miya

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 27 Mar 2010 10:10:42 -0700

it also seems, to me at least, that there are a few involved ops folks
saying: "Hi, we like the idea of /127, we like the simplicity, we
understand how to do this... could you remove the
subnet-router-anycast bits for 'router' instances and let us get back
to operating this network for you?"

It seems that listening to the folks running the network for you, in a
case that's not harmful to every other case you want to use the 96bit
longer addresses... makes some sense.

-Chris

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 27 Mar 2010 10:23:37 -0700

Apologies for the direct folks, I sent this from the wrong address to the list.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 29 Mar 2010 13:17:28 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Saturday, March 27, 2010 1:11 PM
Subject: Re: router vs. host discussion in 6man today for the /127 draft

-Chris

[[WEG]]

+1
We're already using /127s on both Ethernet and SONET point to point WAN and local links between our routers, as well as a number of our links to external peers. Our rationale is basically opposite to those saying that it should be /64s everywhere unless they are convinced otherwise - We don't see a compelling argument in RFC3627 to *not* using /127s in this specific instance. We have explicitly disabled both ND and DAD (we don't want to trigger DAD when we're testing SONET ports to loops) and we're manually assigning the IPv6 addresses on both sides of the interface. IMHO, what's being proposed by draft-kohno-ipv6-prefixlen-p2p-01 is the same as RFC3021, except that the motivation is not as urgent for conserving address space as it was in IPv4. I welcome attempts to point out distinctions between IPv4 and IPv6 which would make this an overgeneralization on my part, but otherwise, I don't understand the resistance to the idea presented by this draft. Call me a long-range optimist, but I'd rather not have to renumber when we determine at some point later that perhaps we should be a bit less wasteful with our addressing because the world has changed in some fundamental way, and that there are some links that will never need EUI-64 support. (eg 5.3.3 of the draft text)

If you believe that the document's language needs to be cleaned up to be more explicit about the cases when /127 isn't harmful, I'm certainly in favor of any recommendations to that effect. Perhaps it needs to be specific in not only invalidating 3627 but also in updating the appropriate sections of 4291 to make the acceptable exception cases clearer - in other words, more closely mirroring 3021 in structure. But I don't see what value is added by sticking to a hard and fast rule of /64 (or even /112 or /126) on a link that will never have more than two routers on it, either by physical limitations in SONET's case or by convention through use of Ethernet as PTP, and will be explicitly configured with an address on both sides, and by the two previous assumptions, will never serve as a LAN segment where /64 for autoconfig is at all necessary.

Even in the slightly higher-risk case where this is a link between two ASBRs and therefore both routers are not controlled by the same party, it's in both parties' interest to ensure proper explicit address configuration, because there is usually an eBGP session between the two addresses that either won't come up or may have an invalid next-hop for any routes learned if the interface is not configured properly.

Wes George

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Mar 2010 07:38:28 +1030

On Mon, 29 Mar 2010 13:17:28 -0500
"George, Wes E [NTK]" <[email-masked]> wrote:

> We're already using /127s on both Ethernet and SONET point to point WAN and local links between our routers, as well as a number of our links to external peers. Our rationale is basically opposite to those saying that it should be /64s everywhere unless they are convinced otherwise - We don't see a compelling argument in RFC3627 to *not* using /127s in this specific instance. We have explicitly disabled both ND and DAD (we don't want to trigger DAD when we're testing SONET ports to loops) and we're manually assigning the IPv6 addresses on both sides of the interface. IMHO, what's being proposed by draft-kohno-ipv6-prefixlen-p2p-01 is the same as RFC3021, except that the motivation is not as urgent for conserving address space as it was in IPv4. I welcome attempts to point out distinctions between IPv4 and IPv6 which would make this an overgeneralization on my part, but otherwise, I don't understand the resistance to the idea presented by this draft. Call me a long-range opt
 im
>  ist, but I'd rather not have to renumber when we determine at some point later that perhaps we should be a bit less wasteful with our addressing because the world has changed in some fundamental way, and that there are some links that will never need EUI-64 support. (eg 5.3.3 of the draft text)
> 

So, I really don't see why LAN segments *need* /64s either then. LAN
segments will never have 2^64 nodes on them either - most only have no
more than a few hundred nodes. Appletalk did autoconf with a fixed
node address size of 8 bits, not 64. It's only limitation was 2^16
network numbers, so if we used more of IPv6's addressing for network
numbers, and go to 8 bit node addresses, we'll have really efficient
addressing on LANs, which most commonly don't have more than 256 nodes.
This will be much better than the waste in IPv6. 

It's probably unlikely that many people will use SEND and other
mechanisms that take advantage of /64s, because the simpler IPv4
solutions will likely be made to work with IPv6. With enough time and
effort, we'll be able to work around or replace any of the mechanisms
that rely on /64s. 

Hopefully having 2^120 bits for network numbers will also satisfy
people who think /48s are small.

Lets not make P2P links a special case. Lets do the job properly. Lets
make node addresses 8 bits or less.

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Mar 2010 08:17:21 +1030

Hi,

The subject pretty much says it. It's extremely wasteful to be
allocating a /64 per subscriber PPP/PPPoE session. 

An alternative model is lay a "virtual" /64 over the top of the 100s or
1000s of PPP/PPPoE sessions, and have the subscriber's PPP IID used to
autoconf the LL and global addresses. However that's vulnerable to the
/64 issues, and because IPv6 over PPP defaults to allowing disabling
DAD, could also suffer from duplicate addresses. There is a caveat to
allow DAD to be re-enabled, but with cheap residential CPE, that
couldn't be relied on.

Also it'd be worth making DHCPv6 support announcing a default
router/route to these end nodes, so that the upstream BRAS doesn't have
to issue periodic RAs. In either the /64 per P2P link or the single
"shared" model, with 100s (or more typically 1000s) of subscribers
attached, the router will have to spend a reasonable amount of
resources on sending RAs down the individual PPP/PPPoE sessions.

Regards,
Mark.

---

From: Tony Li <[email-masked]>
Date: Mon, 29 Mar 2010 14:36:01 -0700

> make node addresses 8 bits or less.

I know of a LAN that's currently operating with more than 30k nodes on it.

I won't embarrass folks by naming names.  ;-)

Tony

---

From: "Frank Bulk - iName.com" <[email-masked]>
Date: Mon, 29 Mar 2010 17:34:30 -0500

Did you get assigned a /48 that you feel that you are address constrained?

The whole point of IPv6 is plentiful addresses.  At this time I'm planning
to assign a /64 per PPPoE link, and if they want it, a /56 via DHCP-PD.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Smith
Sent: Monday, March 29, 2010 4:47 PM
To: Mark Smith
Cc: Becca Nitzan; [email-masked]; [email-masked]; George, Wes E [NTK];
[email-masked]; Miyakawa; [email-masked]
Subject: DHCPv6 support for /127s, for ISP subscriber PPP/PPPoE p2p links
(Re: router vs. host discussion in 6man today for the /127 draft)

Hi,

Regards,
Mark.

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Mar 2010 15:17:27 +0900

> So, I really don't see why LAN segments *need* /64s either then.

as the subject, but not the $subject, has changed, could you please
remove me from the cc:s.  thanks.

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Mar 2010 21:26:43 +1030

Hi Tony,

On Mon, 29 Mar 2010 14:36:01 -0700

> I know of a LAN that's currently operating with more than 30k nodes on it.

With a single IPv4 or IPv6 subnet on it? I'd be impressed if that's the
case. I've seen a 1200 node LAN with it, with 4 x IPv4s /24s on top of
it, proxy arp, and nodes with /16 masks to allow Netbios Name Lookups
to work without having to have a Netbios Name Server. At 10MB of
broadcast traffic every 25 minutes, it was ugly.

Or was your 'LAN' running PPPoE? I've done that too, and that was quite
reasonable. I'm confident you wouldn't be able to scale IPv4 a single
IPv4 subnet over such a 'LAN', but with MLD enabled switches and IPv6
you might be able to.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Mar 2010 21:30:18 +1030

On Tue, 30 Mar 2010 15:17:27 +0900

> remove me from the cc:s.  thanks.

Apologies for that. Can we generalise the subject into non-64 bit
IIDs, as it also covers the /127 case, and nearly all the reasons for
non-/64s on LANs are the same as in the draft?

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Mar 2010 20:09:24 +0900

> non-/64s on LANs are the same as in the draft?

no.  pick one fight at a time.  we are trying to maintain a very narrow
and precise focus.

randy

---

From: Michael Dillon <[email-masked]>
Date: Tue, 30 Mar 2010 11:49:50 +0000

> more than a few hundred nodes.

IPv6 LAN segments do not *NEED* a /64. IPv6 LAN segments *ARE*
a /64 by definition. It has nothing to do with the number of nodes which
are irrelevant in IPv6. Those 64 bits that are not part of the /64 network
prefix, are "interface IDs" which address network interfaces connected
to the network. Currently, most hardware implements IPv6 in the
simplest and most general way so that people who want to use
it in a non-standard way can munge things up, but if you are running
an IPv6 transit network that connects to the IPv6 Internet, then you
are better off sticking with standards.

In any case, a single host could easily have 36 or more IPv6 interface
IDs on it, given the prevalence of 4-core servers capable of holding
32 gigs of RAM and virtualizing 12 machines per core. And given the
rate of technology change, that number (36) is doubling every couple
of years.

Future proof your network and use /64 for every network segment
even if it is only a point-to-point link unless there is a valid technical
reason to make an exception. Conserving address space is not
a technical reason. Ten years from now, nobody will thank you
for conserving addresses that aren't going to be scarce for another
two to three human lifetimes (100-200 years). But they will thank
you for making the network architecture simple and expandable.
There might even be a good reason to change some point-to-point
circuits into multipoint circuits once Ethernet and MPLS have
swept aside the dregs of SDH/PDH/ATM/FR.

--Michael Dillon

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Mar 2010 22:33:31 +1030

On Mon, 29 Mar 2010 17:34:30 -0500

> Did you get assigned a /48 that you feel that you are address constrained?

No.

> to assign a /64 per PPPoE link, and if they want it, a /56 via DHCP-PD.

I'm happy with using /64s for PPPoE links. However, if the /127 draft is
accepted, then I'd want to be able to take advantage of them on
PPP/PPPoE sessions - if there is an approved mechanism available to
save address space I may as well use it.

While RAs do support prefix lengths in their PI option, there isn't a
mechanism specified on how to do autoconf in a /127 (or rather, who
gets the 0 or 1 address). As DHCPv6 is going to be run over that link
anyway to acquire DNS addresses etc., it might be better to build
the /127s autoconf mechanism into that. This new DHCPv6 option could
also imply a default route/router, which the eliminates the requirement
for the upstream BRAS to generate periodic, per-PPPoE session/prefix 
specific RA announcements. That could be a useful thing to eliminate, as
generating pre-PPPoE session specific RAs (due to different prefixes),
could start to be a significant control plane load when there are
multiple 10s of 000s of PPPoE subscribers attached to the same device.

Regards,
Mark.

---

From: Tony Li <[email-masked]>
Date: Tue, 30 Mar 2010 08:39:29 -0700

> With a single IPv4 or IPv6 subnet on it?

Yes.  It's a mesh of L2 switching.

Tony

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 30 Mar 2010 09:24:03 -0700

> non-/64s on LANs are the same as in the draft?

No, because I suspect the consensus that can be reached on non-64 bit IIDs
is not the same as can be reached for /127. For example, I support /127s (I
am among the authors of the draft) but don't support non-64 bit IIDs.

---

From: Egor Zimin <[email-masked]>
Date: Wed, 31 Mar 2010 15:20:55 +0400

I think the "PING-PONG issue" reason alone is sufficient to progress
draft-kohno-ipv6-prefixlen-p2p. Using /64 and other short prefixes is very
convenient for DDoS-attackers. With /64 prefixes they can utilize bandwidth
of p2p(PPP) link up to 255(HopCount) times more, than actual bandwith they
generate...
-- 
Best regards,
Egor Zimin

---

From: Philip Homburg <[email-masked]>
Date: Wed, 31 Mar 2010 13:36:21 +0200

>of p2p(PPP) link up to 255(HopCount) times more, than actual bandwith they

I don't really understand this argument. If ND is enabled then this can't
happen. So the problem is caused in the first place by disabling ND.

Now, the only way a packet can actually ping-pong on a link is if both routers
are prepared to forward packets back over the interface they are coming from.
Now, on any link where a router is advertising itself as a default router
this serves a usefull purpose, but on a router-to-router link sending a
packet back to the link it was coming from is a clear indication of a
routing loop and you can just as well drop the packet.

So you have to both disable ND and be willing to forward packets back to the
link they are coming from to trigger this problem.

---

From: Egor Zimin <[email-masked]>
Date: Wed, 31 Mar 2010 15:59:16 +0400

1. Absence of ND on p2p links is logical. There is no need for ND. There are
only two neighbors. We always know L2 destination address, why should we use
any mechanisms to resolve it ?

2. You are right, "forward packets back to the link they are coming from" is
not normal behaviour for p2p links. But only for P2P(not for Ethernet p2p
"face-to-face").
Unfortunately, this behaviour is normal for a lot of vendors because of
specificity of hardware forwarding. So using /127 looks like a good solution
for this problem.

2010/3/31 Philip Homburg <[email-masked]>

-- 
Best regards,
Egor Zimin

---

From: Rémi Després <[email-masked]>
Date: Wed, 31 Mar 2010 14:00:17 +0200

> non-/64s on LANs are the same as in the draft?

Indeed, all links on which there is need neither for IPv6 link-local addresses nor for neighbor discovery, have no reason to be limited to /64 link prefixes and 64-bit IIDs.

Whether it is better to make directly the generic point, or do things in two phases is a matter for personal appreciation.
What is important IMHO is that technical realities get understood by the community, and it seems we do agree.

RD

---

From: Philip Homburg <[email-masked]>
Date: Wed, 31 Mar 2010 14:07:53 +0200

>any mechanisms to resolve it ?

Because, as is clearly demonstrated by the call for a /127, you don't know if
the address you are forwarding to is actually associated with the peer's
interface. ND not only provides the link layer address but also verifies that
the address is actually there.

>specificity of hardware forwarding. So using /127 looks like a good solution

I'm not against using /127s. I'm not aware of anything that uses that router
anycast address, and that seems to be the only technical reason against /127.

But I think it is everybody's interest if router vendors would provide an
option of not forwarding packets back on links they came from.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 31 Mar 2010 11:55:39 -0400

As far as I can tell, the ping-pong behavior is a bug.
The operators do need some help from the vendors working around the bugs 
until the vendors can fix them.

Separately, it appears that the operators want to use /127 for pt-to-pt 
inter-router links, and I see no good reason to say that they can't.  So 
we probably should modify the specs to permit this.
(Whether I think this is a a great idea or a false economy is 
irrelevant.  This particular case does not conflict with the various 
reasons for wanting /64s as a general model.)

Yours,
Joel

Egor Zimin wrote:
> 1. Absence of ND on p2p links is logical. There is no need for ND. There 
> are only two neighbors. We always know L2 destination address, why 
> should we use any mechanisms to resolve it ?
> 
> 2. You are right, "forward packets back to the link they are coming 
> from" is not normal behaviour for p2p links. But only for P2P(not for 
> Ethernet p2p "face-to-face").
> specificity of hardware forwarding. So using /127 looks like a good 
> solution for this problem.
> 
> 2010/3/31 Philip Homburg <[email-masked] 
> <mailto:[email-masked]>>
>