Subject: [v6ops] GRASP

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Dec 2017 23:42:02 +0000

Brian - what is this GRASP thing:

https://www.ietf.org/id/draft-ietf-anima-grasp-15.txt

First of all, it looks like a protocol specification but it is coming from an
operations WG which seems odd to me. How is it that anima can exist
as an OPS group and produce standards-track specifications?

Second, it looks like it wants to be a link-local discovery protocol that can
replace existing discovery protocols like DHCPv6, IPv6 ND, etc. Is that the
intention - to replace well established protocols with something new?

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Dec 2017 13:02:44 +1300

> as an OPS group and produce standards-track specifications?

Easily. This was a chartered work item and until recently one of the Internet
ADs served as AD for the WG, precisely because we were chartered to do
protocol development.

> intention - to replace well established protocols with something new?

No. It isn't competing with ND or DHCPv6 in the least. GRASP Objectives (the
atoms of discovery) are higher level objects than anything you would discover
with DHCP or ND. There *is* an element of overlap with DNSSD, but we're
working to avoid that becoming a tussle (draft-eckert-anima-grasp-dnssd-00).

You should start with https://tools.ietf.org/html/draft-ietf-anima-reference-model
to get the big picture. Or if you prefer bullet points:
https://github.com/becarpenter/graspy/blob/master/AN-overview.pdf

Regards
    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 Dec 2017 17:29:42 +0000

Hi Brian,

> No. It isn't competing with ND or DHCPv6 in the least.

OK, that is great but whenever we talk about prefix delegation
you say "go see anima" - so I did.

I read draft-ietf-anima-prefix-management which cites both
DHCPv6 PD and GRASP, so I took a high-level pass over GRASP
and saw that it was specifying a new service discovery protocol
which made me wonder whether it was entering into a new
tussle space involving DHCPv6 PD and IPv6 ND.

If there is in fact no tussle, can we say that IPv6 ND is the
mandated neighbor discovery service for IPv6 and that
DHCPv6 PD is the mandated prefix delegation service?
It would make life much easier to be able to cite IPv6ND
and DHCPv6  PD normatively instead of constantly having
to take care to cite them only as examples.

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Tuesday, December 19, 2017 4:03 PM
> To: [email-masked]
> Subject: Re: [v6ops] GRASP
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 20 Dec 2017 21:12:47 +0000

> ... can we say that ...

HNCP (RFC 7788) can be used  to delegate prefixes inside a home network. I don't think there's consensus for stateful DHCPv6 server to be mandated for internal-to-the-home-network use cases.
Barbara

---

From: james woodyatt <[email-masked]>
Date: Wed, 20 Dec 2017 13:29:39 -0800

On Dec 20, 2017, at 13:12, STARK, BARBARA H <[email-masked]> wrote:
> [Fred Template asks?]
>> ... can we say that ...DHCPv6 PD is the mandated prefix delegation service?
> 

I don’t think there is consensus to mandate that prefix delegation of any sort be a feature of non-transit networks. Pretty sure there is a vocal and powerful faction that will contest against any effort to mandate any kind of prefix delegation on networks where general purpose hosts are provided with public Internet connectivity. Which is why I have finally come around on the need to deploy address amplifying NAT66 in home networks.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Dec 2017 22:35:57 +0100

> HNCP (RFC 7788) can be used  to delegate prefixes inside a home network. I don't think there's consensus for stateful DHCPv6 server to be mandated for internal-to-the-home-network use cases.

HNCP is not deployed in the home network I live in.

Where is HNCP deployed?

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Dec 2017 14:50:33 +1300

> HNCP (RFC 7788) can be used  to delegate prefixes inside a home network. I don't think there's consensus for stateful DHCPv6 server to be mandated for internal-to-the-home-network use cases.

Right, and all IETF standards are voluntary anyway. Mandating anything as the
exclusive something is never going to fly.
(And as far as the case Fred raised goes, there was very careful chartering
language for ANIMA to ensure that we didn't trample on HOMENET; and there's
also careful language in draft-ietf-anima-prefix-management to show how
it can fit in with DHCPv6-PD. In a nutshell, the autonomic function manages
prefixes as a resource pool, handing them out to devices that can then
delegate them to non-autonomic devices using PD.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Dec 2017 16:35:25 +1300

> I don’t think there is consensus to mandate that prefix delegation of any sort be a feature of non-transit networks. Pretty sure there is a vocal and powerful faction that will contest against any…

I don't see that argument for homenets. ISPs don't seem reluctant to hand out /64, /56 or /48 to paying subscribers. I can see that if you want to do something fancy while roaming, you might have to deal with a single /128.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Dec 2017 15:07:00 -0800

> I don't see that argument for homenets. ISPs don't seem reluctant to hand out /64, /56 or /48 to paying subscribers. I can see that if you want to do something fancy while roaming, you might have t…

They are very reluctant to deploy CPE gateways that use any current or forthcoming protocol to delegate automatically any portion of their prefix to routers on home network links. In shorter terms, they are happy to hand out /56 (less so /48) to CPE edge routers owned by paying customers, but there is no appetite for supporting customers with interior routers downstream of the CPE edge router. Certainly not in their provider provisioned CPE gateway devices that are more often than not bundled in the service agreement and quietly included in the total charge for access. Oh, they might have plans to use that number space with some non-standard prefix distribution protocol, but it appears there is very little appetite for adopting any standard made available for third parties to use freely.

That’s why anybody planning to offer consumers technology solutions that include IPv6 router functions running on nodes located behind CPE routers are forced to resort to address amplifying NAT to operate as a router on the downstream links and a host on the upstream home network link behind the CPE router. Just as happened with IPv4 for pretty much the same reasons. I’ve spent the better part of three years trying to avoid that conclusion, and my experience in V6OPS and HOMENET has led me to conclude that it was a badly wasted effort. NAT66 is the wave of the future.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 31 Dec 2017 17:05:33 +0100

Le 23/12/2017 à 04:35, Brian E Carpenter a écrit :
>>> HNCP (RFC 7788) can be used  to delegate prefixes inside a home
>>> network. I don't think there's consensus for stateful DHCPv6
>>> server to be mandated for internal-to-the-home-network use
>>> cases.
>> 
>> I don’t think there is consensus to mandate that prefix delegation
>> of any sort be a feature of non-transit networks. Pretty sure there
>> is a vocal and powerful faction that will contest against any
>> effort to mandate any kind of prefix delegation on networks where
>> general purpose hosts are provided with public Internet
>> connectivity. Which is why I have finally come around on the need
>> to deploy address amplifying NAT66 in home networks.
> 
> I don't see that argument for homenets. ISPs don't seem reluctant to
> hand out /64, /56 or /48 to paying subscribers. I can see that if you
> want to do something fancy while roaming, you might have to deal with
> a single /128.

I am not sure what did you mean by something fancy?

A delegated /56 to a UE can stay stable during on-off and handover 
events, although I am also curious whether it resists during roaming.

Ideally, there would be no need to use /128 instead of /56 in order to 
be roaming-resistent.

Alex