Subject: 6man discussion on /127 document @ IETF78

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 28 Jul 2010 02:42:56 -0500

I agree with Dave Thaler from yesterday's discussion in 6man related to
the /127 draft.  In the two router scenario for /127, each router is
off-link to the other and then one has nothing to bother about for
anycast address.  Folks are also encouraged to read the IPv6 Subnet
Model RFC where off-link has been clarified  - RFC 5942.

So now is there anything left to specify for this /127 issue that needs
to be described in draft-kohno-ipv6-prefixlen-p2p?

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: Ole Troan <[email-masked]>
Date: Wed, 28 Jul 2010 10:39:42 +0200

> I agree with Dave Thaler from yesterday’s discussion in 6man related to the /127 draft.  In the two router scenario for /127, each router is off-link to the other and then one has nothing to bother about for anycast address.  Folks are also encouraged to read the IPv6 Subnet Model RFC where off-link has been clarified  - RFC 5942.
>  
> So now is there anything left to specify for this /127 issue that needs to be described in draft-kohno-ipv6-prefixlen-p2p?

my view is entirely different.
the 64 bit boundary is a suggested policy and not normative. IPv6 is not classful.
two routers on a /127 are on-link to each other. two /128s would make them off-link.

a off-link node cannot make any assumption on the use of subnet-router anycast addresses, reserved anycast space or the validity of u/g bits.

I support adopting the draft as a working group item now.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 28 Jul 2010 03:49:25 -0500

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, July 28, 2010 10:40 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; Dave Thaler
Subject: Re: 6man discussion on /127 document @ IETF78

>two routers on a /127 are on-link to each other. two /128s would make
them off-link.

If an RA with no PIO is configured on each router the routers are
off-link even if they addresses are /127.

Hemant

---

From: Dave Thaler <[email-masked]>
Date: Wed, 28 Jul 2010 08:51:01 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole
> Troan
> To: Hemant Singh
> > I agree with Dave Thaler from yesterday's discussion in 6man related to the
> /127 draft.  In the two router scenario for /127, each router is off-link to the
> other and then one has nothing to bother about for anycast address.  Folks are
> also encouraged to read the IPv6 Subnet Model RFC where off-link has been
> clarified  - RFC 5942.
> >
> > So now is there anything left to specify for this /127 issue that needs to be
> described in draft-kohno-ipv6-prefixlen-p2p?
> 
> the 64 bit boundary is a suggested policy and not normative.

That's not true.  RFC 4291 is the addressing architecture and normatively
states:

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Furthermore 129 addresses in every subnet are reserved.  See RFC 2526.

   Within each subnet, the highest 128 interface identifier values are
   reserved for assignment as subnet anycast addresses.

These are assigned by IANA (http://www.iana.org/assignments/ipv6-anycast-addresses)

So you cannot have any unicast addresses in any subnet with a prefix
longer than /120.   However, the point is, you don't need to.
You just use the off-link model.

>  IPv6 is not classful.

Be careful not to confuse the terminology.  The definition of "on-link" is in RFC 4861.

> 
> a off-link node cannot make any assumption on the use of subnet-router
> anycast addresses, reserved anycast space or the validity of u/g bits.

That's not true either.  The RFCs quoted above have no such restriction
on what off-link nodes can assume.

-Dave

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Matsuzaki Yoshinobu <[email-masked]>
Date: Wed, 28 Jul 2010 18:14:25 +0900 (JST)

Hi,

Date: Wed, 28 Jul 2010 02:42:56 -0500
"Hemant Singh (shemant)" <[email-masked]> wrote
> anycast address.

To establish an external-BGP session on a link that two routers are
connected to, the two routers need to be on-link each other on the link.
And we are using /127 for these links in our network.

> Folks are also encouraged to read the IPv6 Subnet Model RFC where
> off-link has been clarified - RFC 5942.

It seems the RFC 5942 is mostly for hosts, not for routers.
Thanks,
-----
Matsuzaki Yoshinobu <[email-masked]>
 - IIJ/AS2497  INOC-DBA: 2497*629

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Jul 2010 11:36:41 +0200

Dave,

>   constructed in Modified EUI-64 format.

right, no RFC2119 language there. apart from that, implementations support and people are using prefixes longer than /64 today. so we can either choose to put our head in the sand or adjust specifications to reality.

> longer than /120.   However, the point is, you don't need to.

I think the purpose of this draft is to say that you can. but you cannot use reserved anycast addresses on these links, nor can you make assumptions about the u/g bits.

> Be careful not to confuse the terminology.  The definition of "on-link" is in RFC 4861.

what definition do you use?

if you want to define two nodes as off-link to each other you might use two /128s.
if I use a /127 then this bullet of 4861's on-link definition applies. i.e these two nodes are directly connected, as they have addresses out of the same /127.

- it is covered by one of the link's prefixes (e.g.,
                      as indicated by the on-link flag in the Prefix
                      Information option), or

(it appears to me that people coming at this from a routing perspective have quite different models in mind than people coming at it from a host perspective...)

> on what off-link nodes can assume.

my point is that an implementation cannot assume that setting the last 64 bits to zero will give you a valid subnet-router anycast address. nor that taking a random 64 bit prefix and using the reserved anycast address will work nor that you can glean anything certain from u/g bits.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 28 Jul 2010 04:53:44 -0500

-----Original Message-----
From: Matsuzaki Yoshinobu [mailto:[email-masked]] 
Sent: Wednesday, July 28, 2010 11:14 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]
Subject: Re: 6man discussion on /127 document @ IETF78

>And we are using /127 for these links in our network.

We were told in the 6man presentation yesterday that the two routers are
not connected to any hosts or any other node but just connected to each
other.  So where does the question arise wrt external BGP sessions? 

>It seems the RFC 5942 is mostly for hosts, not for routers.

We are discussing off-link model and RFC 5942 is described in this RFC.
Further, when an interface of a router acquires an IPv6 address or
receives an RA, the interface is acting as a host.

Hemant

---

From: Miya Kohno <[email-masked]>
Date: Wed, 28 Jul 2010 19:14:58 +0900

Hi,

The draft is discussing about inter-router backbone link, where "directly-connected neighbor" has a significant meanings from routing protocol point of view.  So it needs to be assumed "on-link".

Miya

Sent from my iPhone

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 28 Jul 2010 07:54:41 -0500

-----Original Message-----
From: Miya Kohno [mailto:[email-masked]] 
Sent: Wednesday, July 28, 2010 12:15 PM
To: Hemant Singh (shemant)
Cc: Matsuzaki Yoshinobu; [email-masked];
[email-masked]
Subject: Re: 6man discussion on /127 document @ IETF78

>The draft is discussing about inter-router backbone link, where
"directly-connected neighbor" has a significant meanings from routing
protocol point of view.  So it needs to be assumed "on-link".

Even if the two routers are in the off-link model for the IPv6 address
and RA configuration, the network between the two routers is still a
directly connected network.  One router sends his packet to the other
without going thru any routed hop.  So what specifically fails for BGP
with an off-link addressing and RA configuration?

Hemant

---

From: Miya Kohno <[email-masked]>
Date: Wed, 28 Jul 2010 23:58:20 +0800

Hi,

>> "directly-connected neighbor" has a significant meaning from 
>> routing protocol point of view. So it needs to be assumed "on-link".

> with an off-link addressing and RA configuration?

A quote from IOS manual:

------------------
A BGP routing process will verify the connection of single-hop eBGP
peering session (TTL=254) to determine if the eBGP peer is directly
connected to the same network segment by default. If the peer is not
directly connected to same network segment, connection verification will
prevent the peering session from being established.
------------------
http://cisco.biz/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_n1g
t.html#wp1109875

Miya

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 28 Jul 2010 18:49:18 -0400

(most of the discussion seems to be revolving around a simple, to me,
phrasing problem, but)

> receives an RA, the interface is acting as a host.

anyone that configures a router with RA is headed for disaster
anyway... (not a cpe device mind you, though most of those will get
addressing via pppoe/pd and not RA so...)

I think the case that maz/miyao outlined is a normal internet backbone
router, it has many interfaces (several hundred), it has many (several
hundred) bgp sessions to neighbors. today the interfaces are being
configured as /127's in some cases.

This draft, which I support as being a working group item (we really
should just discuss that portion first, then argue language issues),
only seeks to clarify that using /127's (or for thayler: "two
addresses on a single link, which may coincidentally be adjacent
addresses") is common operations practice and should be supported by
routing equipment vendors.

-chris
(can we call the question in a clean/new email about adoption pls?
There was interest in the room for same.)

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 28 Jul 2010 18:53:29 -0400

>> Even if the two routers are in the off-link model for the IPv6 address

'off link' does not (for the case of this discussion) mean 'off the
ethernet wire', it's a semantic distinction that thayler and shermant
are attempting to make in order to keep the authors from having to go
off and muck with a bunch of other already finalized documents.

So... in short 'off link' just means 'dont call this a /127, call this
two ips that happen to live together on the same piece of
ethernet/sonet/frame/wifi'

-chris

---

From: Brian Haberman <[email-masked]>
Date: Wed, 28 Jul 2010 18:55:48 -0400

Hi Chris,

> There was interest in the room for same.)

That is what I said I would do as soon as the draft is published.

Regards,
Brian

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 28 Jul 2010 19:11:14 -0400

> That is what I said I would do as soon as the draft is published.

oh ah-ha! :) excellent. I retract my comment. thanks!
-chris

---

From: Miya Kohno <[email-masked]>
Date: Thu, 29 Jul 2010 08:24:41 +0800

Hi Brian, 6man WG,

Sorry for the delay in publishing. Comments/Suggestions would be greatly
appreciated.

http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-02.txt

Abstract:
On inter-router point-to-point links, it is useful for security and
other reasons, to use 127-bit IPv6 prefixes.  Such a practice parallels
the use of 31-bit prefixes in IPv4 [RFC3021].  This document outlines
some of these reasons and specifies that 127-bit IPv6 prefix lengths
must be supported on such links.

Thanks, 
Miya
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Thursday, July 29, 2010 7:56 AM
To: [email-masked]
Subject: Re: 6man discussion on /127 document @ IETF78

Hi Chris,

Regards,
Brian

---

From: Miya Kohno <[email-masked]>
Date: Thu, 29 Jul 2010 08:28:07 +0800

Hi Chris,

According to the rfc4861, "off-link" is defined as follows: 
"the opposite of "on-link"; an address that is not assigned to any interfaces on the specified link."

BGP checks if an eBGP peer is directly connected by comparing the peer address against directly connected interface addresses.

So I was afraid it could be incompatible.

Miya
-----Original Message-----
From: Christopher Morrow [mailto:[email-masked]] 
Sent: Thursday, July 29, 2010 7:53 AM
To: Miya Kohno
Cc: Hemant Singh (shemant); [email-masked]; [email-masked]
Subject: Re: 6man discussion on /127 document @ IETF78

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Jul 2010 03:59:30 -0400

> So I was afraid it could be incompatible.

not arguing that, though for the purposes of the router's view these 2
addresses are in fact adjacent on the same link.

dthayler's issue is purely (I think) semantic with respect to the ipv6
rfc portions of the discussion... 'if you say slash-27, you must deal
with all this other baggage. if you say off-link addresses which may
happen to be adjacent, you do not.'

is it 'ok' to define this term differently in each document/context?

-chris

---

From: Brian Haberman <[email-masked]>
Date: Thu, 29 Jul 2010 04:48:07 -0400

On 7/28/10 8:28 PM, Miya Kohno wrote:
> Hi Chris,
> 
> According to the rfc4861, "off-link" is defined as follows: "the
> opposite of "on-link"; an address that is not assigned to any
> interfaces on the specified link."
> 
> BGP checks if an eBGP peer is directly connected by comparing the
> peer address against directly connected interface addresses.
> 

I don't think it is.  Router implementations that I am familiar with do
not use the NDP prefix state (on- or off-link) to determine if a BGP
peer is directly connected.

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 29 Jul 2010 05:37:22 -0500

-----Original Message-----
From: Miya Kohno [mailto:[email-masked]] 
Sent: Wednesday, July 28, 2010 11:58 AM
To: Hemant Singh (shemant)
Cc: Matsuzaki Yoshinobu; [email-masked];
[email-masked]
Subject: RE: 6man discussion on /127 document @ IETF78

And the problem with eBGP is? If a BGP control message is initiated by
one of the two routers and sent to the other router, no TTL is
decremented when the other routers receives this message.  Only if the
control is forwarded by the receiving router out any interface then the
router decrements the TTL.  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 29 Jul 2010 05:46:18 -0500

Right, Brian.

Folks should stop confusing between ND off-link with directly connected
routes.  Directly connected route determination is a L3 concept that
checks for how many hops exist between two routers by tracking the TTL.
One of the reasons we wrote the Pv6 Subnet model document was to point
out broken OS implementations who had merged the Neighbor cache with the
Destination cache (FIB).  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Thursday, July 29, 2010 4:48 AM
To: [email-masked]
Subject: Re: 6man discussion on /127 document @ IETF78

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 29 Jul 2010 06:53:11 -0500

>Sent: Wednesday, July 28, 2010 6:49 PM
>Cc: Matsuzaki Yoshinobu; [email-masked]; [email-masked]

>addressing via pppoe/pd and not RA so...)

So where does the document say how the IPv6 addresses are assigned?
PPPOE is one, manual configuration is another. SLAAC is another - heck
if one has two routers back to back (I don't care if the two routes are
in the Internet core) I can configure an interface on one router for
IPv6 address autoconfiguration to get a SLAAC address from the other
router on the same link between the two routers using the RA.  RA was
pointed out merely to show how one signals off-link (send traffic to
default router). What both Dave Thaler and I are saying that all the
router has to do is use the ND off-link model (for data forwarding) when
a /127 is configured and then they is no issue with Subnet-Router
Anycast Address.  

>routing equipment vendors.

Sorry, unless the problem and deployment space is articulated properly,
I do not support this work. I appreciate the problem but I do not think
the document is ready to be accepted as a WG work item.  Also, if Dave
and I are saying, have the router use ND off-link model and then there
is no issue with the Subnet-Router Anycast Address. So now why do we
even need the draft-kohno-ipv6-prefixlen-p2 document?  

Hemant

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 30 Jul 2010 01:06:28 +0200

At Wed, 28 Jul 2010 19:14:58 +0900,
Miya Kohno <[email-masked]> wrote:

> "directly-connected neighbor" has a significant meanings from

I think we should specifically clarify what are "significant
meanings", and their implication with "on-link".  In particular, it
would be helpful to clarify if a common subnet prefix (regardless of
how long it is) has to be shared between the two routers.

If a "significant meaning" is about the TTL/hop limit check of eBGP to
confirm the peer is attached to a directly connected link, the peer
address doesn't necessarily have to share the same prefix with the
local address of the p2p link.  The router only has to know the peer
address is reachable via the p2p link, which could be e.g. configured
by a manually installed host route.  It might even be automatically
advertised/learned via an RA with a prefix information option with the
L bit on for the "/128" prefix, although I don't know if the original
intent of RFC4861 specification allows such an automatic prefix
configuration between routers or if an existing router implementations
support that.

If another "significant meaning" is the check "if an eBGP peer is
directly connected by comparing the peer address against directly
connected interface addresses" (quoted from another message of this
thread), I'm not sure if this is a requirement of the protocol or a
requirement/convention of particular implementations.  Regarding the
protocol specification, RFC4271 doesn't seem to require it: for
example, section 5.1.3. 2) states that the source address of the
peering connection can be used for NEXT_HOP, whether or not that
address shares the same prefix with the peer.

If "sharing the same prefix" is not a hard requirement, it would be
less controversial to use the so called "off-link" model, that is, the
two routers assign two independent addresses to each end of the p2p
link, e.g. 2001:db8:1111:2222::0/128 and 2001:db8:1111:2222::1/128,
and ensure these addresses are reachable via the p2p link by some
other method as mentioned above.  It might be even acceptable (for the
"address architecture police") to actually configure them as belonging
to a "/127" prefix 2001:db8:1111:2222::0/127, as an internal
implementation/operational practice, as long as the externally
observable behavior is the same as the "off-link" model.

btw, not being a router operator (or implementor), I personally don't
have a strong opinion on this issue, but I see the need for
clarification.  Even if the point is so obvious to some wg members (of
which I'm not included), if it's not clear for a sufficiently large
group of people, it should be worth clarifying.  So I basically
support (eventually) adopting this draft as a wg document.  But it may
be better to begin with a clear problem statement without including
any specific solution.  And, as a result of that, the appropriate wg
may be an O&M one (most likely v6ops in that case) rather than this
wg.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Miya Kohno <[email-masked]>
Date: Fri, 30 Jul 2010 15:37:27 +0800

Hello,

Thank you for your comments. Thanks to Jinmei's and other messages to the mailing list, I got keenly aware of the fact that what is obvious and what is unobvious depends much on the background of each person. I thought "directly-connected" was an obvious concept, but it was not. I'm sorry for the ambiguity.

> If another "significant meaning" is the check "if an eBGP peer is directly connected by comparing the peer address against directly connected interface addresses" (quoted from another message of this thread), I'm not sure if this is a requirement of the protocol or a requirement/convention of particular implementations.  Regarding the protocol specification, RFC4271 doesn't seem to require it: for example, section 5.1.3. 2) states that the source address of the peering connection can be used for NEXT_HOP, whether or not that address shares the same prefix with the peer.

Yes, it can. But it matters and is distinguished. It's hard to tell if it's just a convention or not.  However, if there is a gap between the protocol theory and the reality (operational practice and actual implementation), I think it's good to make some concession. 

It's OK to regard the /127 usage as an instance of "off-link", especially if it's less controversial. Thanks again for the inputs.

Miya
-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
Sent: Friday, July 30, 2010 8:06 AM
To: Miya Kohno
Cc: Hemant Singh (shemant); [email-masked]; [email-masked]
Subject: Re: 6man discussion on /127 document @ IETF78

---
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Sat, 31 Jul 2010 11:47:51 +0930

On Wed, 28 Jul 2010 18:49:18 -0400

> addressing via pppoe/pd and not RA so...)

I wouldn't be so sure about that - the CPE draft says the following
about WAN interface configuration, with Router Discovery i.e. RAs is a
MUST -

 W-1:  When the router is attached to the WAN interface link it MUST
         act as an IPv6 host for the purposes of stateless or stateful
         interface address assignment ([RFC4862] / [RFC3315]).

   W-2:  The IPv6 CE router MUST generate a link-local address and
         finish Duplicate Address Detection according to [RFC4862] prior
         to sending any Router Solicitations on the interface.  The
         source address used in the subsequent Router Solicitation MUST
         be the link-local address on the WAN interface.

   W-3:  Absent of other routing information the IPv6 CE router MUST use
         Router Discovery as specified in [RFC4861] to discover a
         default router(s) and install default route(s) in its routing
         table with the discovered router's address as the next-hop.

   W-4:  The router MUST act as a requesting router for the purposes of
         DHCPv6 prefix delegation ([RFC3633]).

   W-5:  DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation
         (IA_PD) SHOULD be done as a single DHCPv6 session.

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 31 Jul 2010 10:06:11 -0400

> about WAN interface configuration, with Router Discovery i.e. RAs is a

I did say 'not a cpe device'... I would point out that a /64 with your
customer on it is a very large place to hide :) (nd probing/scraping
probably finds the customer easily,  but strikes me as heavyweight to
find a customer you know is at the end of a ptp dlci/vc)

>         (IA_PD) SHOULD be done as a single DHCPv6 session.

these seem good though, in principle. I wonder how (probably not for
this list/discussion though) this works out in practice.

I still hold to the 'anyone who uses RA for router (real router, not
cpe) interface address assignment is headed for disaster' there's no
way to manage/monitor/maintain/etc in a non-deterministic config such
as that. operations folks heads will explode :(

Thanks!
-Chris

---

From: Mark Smith <[email-masked]>
Date: Sun, 1 Aug 2010 10:57:09 +0930

On Sat, 31 Jul 2010 10:06:11 -0400
Christopher Morrow <[email-masked]> wrote:

> I did say 'not a cpe device'...

I was replying to the your comment in brackets about CPE provisioning. I
should have been clearer.

> I would point out that a /64 with your

I think it can be on topic if scalability on protocols dictates updates
to RFCs. For example (although it may already be legal), a slight
update to allow unsolicited RAs to have unicast layer 3 destinations may
be necessary to help scale RA operation on customer aggregation routers
carrying 1000s of subscribers. The other way to mitigate or remedy it
would be to wind up the values of RA periodic timers. In a broadband
PPPoE environment, an RA once an hour to each subscriber would probably
be enough.

> as that. operations folks heads will explode :(

I agree.

In my experience, the CPE space is the more interesting /
challenging at the moment. 

Regards,
Mark.