Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 21 Oct 2017 21:10:22 +0400

Hi all,

A few years ago (2006), I’ve worked in this document (intended status was informational):

https://tools.ietf.org/html/draft-palet-v6ops-point2point-01

At that time, it received many inputs but somehow the work was not continued.

Recently I’ve discovered that many networks are actually using this approach, so I think now is worth for a BCP.

I’ve reused most of the text, updated it, used new references and even indicated that since 2012 a DHCPv6-PD option is available to support this approach.

https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-from-customer-prefix/?include_text=1

Inputs welcome!

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: sábado, 21 de octubre de 2017, 20:57
Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
Asunto: New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt

    A new version of I-D, draft-palet-v6ops-p2p-from-customer-prefix-00.txt
    has been successfully submitted by Jordi Palet Martinez and posted to the
    IETF repository.
    
    Name:		draft-palet-v6ops-p2p-from-customer-prefix
    Revision:	00
    Title:		Using /64 from Customer Prefix for the Inter-Router Link
    Document date:	2017-10-21
    Group:		Individual Submission
    Pages:		6
    URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-p2p-from-customer-prefix-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-from-customer-prefix/
    Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-p2p-from-customer-prefix-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6ops-p2p-from-customer-prefix-00

    Abstract:
       This document describes the usage of a /64 from the customer prefix
       for numbering IPv6 point-to-point links.

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Oct 2017 13:17:48 +0200 (CEST)

Hi,

So while this draft presents an optimization that might be good to 
document, it's also my opinion that it needs to clearly define what a 
"point to point" link is.

The approach works fine on PPP/HDLC/POS type links, but it won't work on a 
direct fiber cable (L1 point to point with "IPoE") but that is running 
ethernet and configured as a broadcast medium (default configuration).

If I were to give an routing engineer from Sweden (where PPPoE isn't 
widely used) this document, I'd imagine that person would become confused 
by this document in its current state.

On Sat, 21 Oct 2017, JORDI PALET MARTINEZ wrote:

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

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 23 Oct 2017 17:17:09 +0400

Hi Mikael,

First of all, thanks for your feedback.

I understand that what you’re proposing is that I clearly state that in the scope of this document somehow “point-to-point link” is not considering “L1 point to point with IPoE” ?

Or do you think some alternative text can specify better if it useful in that case and can actually work?

I wonder if this consideration was done when RFC6164 was being cook ?

Regards,
Jordi

-----Mensaje original-----
De: Mikael Abrahamsson <[email-masked]>
Organización: People's Front Against WWW
Responder a: <[email-masked]>
Fecha: lunes, 23 de octubre de 2017, 15:17
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt

    Hi,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Oct 2017 15:52:11 +0200 (CEST)

> I wonder if this consideration was done when RFC6164 was being cook ?

A /127 will work on ethernet and PPP/POS/HDLC alike.

Assigning a /48 to send that entire /48 down the link does not work on 
ethernet (because it'll do ND for all addresses within that /48), but it 
works on PPP/POS/HDLC links.

So what I would like is a paragraph that clearly states that the proposal 
with /48 on the inteface is designed for point-to-point non-broadcast L2 
mediums and doesn't work on broadcast mediums that rely on ND.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 29 Oct 2017 11:22:40 +0100

Hi all,

I’ve not got any further inputs (except some private messages confirming that some other providers that I was not aware of are also using this), so I’ve included some text to clarify Mikael suggestion here, both in the abstract and intro. No further changes.

Here is the new document:

https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-from-customer-prefix/

Regards,
Jordi

-----Mensaje original-----
De: Mikael Abrahamsson <[email-masked]>
Organización: People's Front Against WWW
Responder a: <[email-masked]>
Fecha: lunes, 23 de octubre de 2017, 15:52
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt

    non-broadcast L2

---

From: Mark Smith <[email-masked]>
Date: Mon, 30 Oct 2017 08:27:59 +1100

On 24 Oct. 2017 12:52 am, "Mikael Abrahamsson" <[email-masked]> wrote:

Hi Mikael,
> I understand that what you’re proposing is that I clearly state that in
> the scope of this document somehow “point-to-point link” is not considering
> “L1 point to point with IPoE” ?
>

Actually, it doesn't really.

If the router at the other end of the link doesn't have the address, and
has a covering route e.g. the /48, ::/0, or something in between, it will
send the packet back onto the link, causing a forwarding loop.

People assume /127s solve this problem, but they only do if the operator(s)
of the devices at the ends of the link is(are) disciplined and configure
the /127 addresses on both ends. It is valid per IPv6 to have a /127 only
present on one end of the link; no errors will be generated by this
"misconfiguration". (It's valid for "no" addresses to be (manually)
configured on a link, because Link-local addresses are autoconfigured, and
ND, ICMPv6 and routing protocols like OSPF use LLs.)

The only way to be sure of the existence of an address is to either probe
for its existence, or to observe it being used. The outcome of NS/ND is
more than just resolving an IPv6 address into a link-layer address, it also
determines the existence of the address.

I think ND should be used on PPP,/POS etc. links for that reason. It
ensures the address is present on the link before trying to send a packet
to it. RFC4861 seems to be saying that because it says it applies to all
link types, and it only makes an exception of NBMA links.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Sun, 29 Oct 2017 22:49:16 +0100

Mark,

> On 29 Oct 2017, at 22:27, Mark Smith <[email-masked]> wrote:
> 
> I think ND should be used on PPP,/POS etc. links for that reason. It ensures the address is present on the link before trying to send a packet to it. RFC4861 seems to be saying that because it says it applies to all link types, and it only makes an exception of NBMA links.

The IPv6 implementations I work on, only does address resolution on link types which have L2 addresses. 

There’s nothing stopping you from doing it on those links, but I can certainly find no requirement to do it in 4861 either. 

Best regards 
Ole