Subject: Fwd: New Version Notification for draft-dykim-6man-sid6-00.txt

From: DY Kim <[email-masked]>
Date: Mon, 3 Sep 2018 16:51:51 +0900

Hi,

I’ve reposted a draft, this time to 6man, which was posted to 6ops about a year ago but fell out of scope there since it involves some changes to NDv6/DAD with added texts.

I’d like to see whether there should be any interest in this draft within the 6man group, possibly enough to justify the modification of NDv6/DAD as suggested in this draft.

Your comments are solicited.

---
DY

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-dykim-6man-sid6-00.txt
> Date: 3 September 2018 at 16:46:04 GMT+9
> To: "DY Kim" <[email-masked]>
> 
> 
> A new version of I-D, draft-dykim-6man-sid6-00.txt
> has been successfully submitted by DY Kim and posted to the
> IETF repository.
> 
> Name:		draft-dykim-6man-sid6
> Revision:	00
> Title:		Subnet ID Deprecation for IPv6
> Document date:	2018-09-03
> Group:		Individual Submission
> Pages:		17
> URL:            https://www.ietf.org/internet-drafts/draft-dykim-6man-sid6-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-dykim-6man-sid6/
> Htmlized:       https://tools.ietf.org/html/draft-dykim-6man-sid6-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dykim-6man-sid6
> 
> 
> Abstract:
>   Deprecation of the subnet ID in IPv6 networking is proposed; the
>   subnet ID is set to zero so that all nodes in a site carry the same
>   prefix.  While the procedures for neighbor discovery and duplicate
>   address detection have to be changed, possible simplification gains
>   in IPv6 networking including that of intra-site host- and subnet-
>   mobility might be worth the modification.  Site-external behaviors
>   don't change through this modification, enabling incremental
>   deployment of the proposal.  Sites of manageable sizes for which
>   scalability is not much a critical issue might consider the mode of
>   operation proposed in this document.
> 
> 
> 
> 
> 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
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 3 Sep 2018 17:09:20 +0900

Section 4.7: No. Please just no.

Furthermore, I fail to see how any of this makes practical sense.  The
SubnetID wasn't ever anything explicitly communicated to clients, at
least where SLAAC was involved -- they just received a /64 in the PIO
an that was that.

3.3: Site-wide DAD?  This seems like a potentially huge self-DDOS vector.

On Mon, 3 Sep 2018 at 16:52, DY Kim <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: DY Kim <[email-masked]>
Date: Mon, 3 Sep 2018 17:19:07 +0900

in-line.

---
DY

> On 3 Sep 2018, at 17:09, Erik Kline <[email-masked]> wrote:
> 

Taken.

> 3.3: Site-wide DAD?  This seems like a potentially huge self-DDOS vector.

Would like to see more opinion on this.

---

From: DY Kim <[email-masked]>
Date: Mon, 3 Sep 2018 17:35:58 +0900

---
DY

> On 3 Sep 2018, at 17:09, Erik Kline <[email-masked]> wrote:

Perhaps, you’ve made two independent comments below.

Taken.

> least where SLAAC was involved -- they just received a /64 in the PIO

Not explicitly, but implicitly. All nodes on the on-link prefix (as ascribed by PIO) are assumed to be on-link, directly reachable on the same ‘subnet(link)' as the host involved resides in.

The host’s address changes as it moves to a different link, whereas it doesn’t in the scheme proposed in this draft.

This invariance of the host’s address over mobility across links within a site is the essence of the scheme proposed.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Sep 2018 07:47:36 +1200

On 2018-09-03 20:35, DY Kim wrote:
...
> This invariance of the host’s address over mobility across links within a site is the essence of the scheme proposed.

Why is that useful?

   Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 3 Sep 2018 22:45:10 +0200

> Your comments are solicited.

From a quick glance it looks like you have re-invented multilink subnet routing.
Which of one flavous is described in https://tools.ietf.org/html/draft-ietf-ipv6-multilink-subnets-00
That particular proposal didn’t go anywhere, for the reasons described in RFC4903.

The basic idea was to share a /64 across multiple IPv6 links.
Steve never wrote down the details, but today, we’d probably do a combination of ND with ARO and an IGP.
Possibly with some modifications. Detecting movement and whenever someone leaves the link is the tricky part.

I would certainly be interested in work in this area.

Cheers,
Ole

---

From: DaeYoung KIM <[email-masked]>
Date: Tue, 4 Sep 2018 08:30:12 +0900

May I repeat the text of 4.10 as a first response?:
4.10. 
o  Transport connection resilience for intra-site mobile nodes can be provided with no extra infrastructure like mapping servers found in most LIS protocols [HIP][ILNP][LISP], resulting in a significant resource saving. 
o  An equivalent incentive in comparison with the legacy IPv6 networking would be that intra-site mobility, and that faster, can be provided inherently by any interior link-state protocols, with no hassle of installing MIPv6 functionalities on every router in a site. Considering that a site can be arbitrarily large, this can be a considerable additional resource saving in terms of network operation.

Sent from my iPhone

> On 4 Sep 2018, at 04:47, Brian E Carpenter <[email-masked]> wrote:
>

---

From: DaeYoung KIM <[email-masked]>
Date: Tue, 4 Sep 2018 08:42:35 +0900

> That particular proposal didn’t go anywhere, for the reasons described in RFC4903.

I didn’t know of the two documents. I’ll have a look and provide more detailed opinion.

Offhand response would be...

> The basic idea was to share a /64 across multiple IPv6 links.

... in contrast to my sharing it across the whole site...? As for me, extending the idea across the whole site might have to be justified if any.

> Possibly with some modifications.

Would, of course, be best if we don’t have to change any existing specs to do the job.

> Detecting movement and whenever someone leaves the link is the tricky part.

Yes.

> I would certainly be interested in work in this area.

Happy to hear that.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Sep 2018 13:57:45 +1200

> o  An equivalent incentive in comparison with the legacy IPv6 networking would be that intra-site mobility, and that faster, can be provided inherently by any interior link-state protocols, with no…

Since current reality is that applications need to be agile with
respect to address changes, and even IP version changes, I find it
increasingly hard to justify effort on address stability for mobile
nodes.

(See the recent v6ops thread:
https://mailarchive.ietf.org/arch/msg/v6ops/-5DaSE41dmqLVkOWEbUoUtRCS3A )

    Brian

---

From: DY Kim <[email-masked]>
Date: Tue, 4 Sep 2018 11:15:11 +0900

How about this?:

“Transport connection resilience for intra-site mobile nodes can be provided with no extra infrastructure like mapping servers found in most LIS protocols [HIP][ILNP][LISP], resulting in a significant resource saving.”

With changing addresses, a hype of proposals (in the class of ID/Locator Separation protocols) deal with separate Transport Connection IDs to ensure transport connection resilience.

The current scheme provides that transport connection resilience, at least within a site, without employing an extra number space of Transport Connection IDs.

---
DY

> On 4 Sep 2018, at 10:57, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 3 Sep 2018 19:41:54 -0700

> increasingly hard to justify effort on address stability for mobile
Brian,

I'm not sure I would agree with that. If mobility is a very rare event
then maybe this is true, but there are also cases where a mobile
device might be doing handover to different cell sites every few
seconds (consider a smartphone on a high speed train). Overhead to
reestablish all connections constantly and renegotiate security could
very well adversely impact user experience. Also, not all applications
and devices will handle and address change event gracefully, for
instance there could be devices tethered downstream to mobile devices
that aren't "mobile devices" and aren't prepared to deal with high
rate of address change.

Eliminating the subnet-ID may also have a positive effect on security
and privacy. Again, consider the mobile case where each cell has a
subnet-ID and each time a device connects it gets an address in that
subnet. Problem is that the network prefix in devices addresses may
reveal specific geo-location of a device (and hence a person in case
of personal device). Eliminating the sub-net prefix and assigning
addresses out of a larger pool of a provider prefix should be better
for privacy. This privacy issue is discussed in some depth in
https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-00--
I think the mobile addressing model there is similar to what is being
proposed in this draft.

Tom

---

From: Ole Troan <[email-masked]>
Date: Tue, 4 Sep 2018 09:22:51 +0200

> increasingly hard to justify effort on address stability for mobile

Applications need to, perhaps, but doesn’t that require a fundamental change in transport too?
Can you name any applications that are?
I can think of mosh, but I’m hard pressed to find other good examples.

Cheers,
Ole

---

From: DY Kim <[email-masked]>
Date: Tue, 4 Sep 2018 17:29:49 +0900

in-line.
---
DY

> Which of one flavous is described in https://tools.ietf.org/html/draft-ietf-ipv6-multilink-subnets-00.

If a site consists of a single subnet, SID6 (my model) should basically reduce to the multi-link subnet (MLS?) model. A difference might be that SID6 explicitly talks about deprecation of the subnet ID whereas MLS is silent about that.

To retain that difference, SID might have to successfully justify the additional benefit of having the subnet ID deprecated.

> That particular proposal didn’t go anywhere, for the reasons described in RFC4903.

RFC4930 comes quite discouraging.

> Possibly with some modifications.

Is it possible that we get more elaboration of your updated idea, please? Is there a possibility for your updated idea to converge with SID6 in some way?

> Detecting movement and whenever someone leaves the link is the tricky part.

As for a node emerging on a link, I’ve ‘naively?’ assumed that such a ‘link-up’ detection is already part of IGP (OSPF or IS-IS) protocols.

As for a node leaving a link, it might be tricky to detect as you point out. I’m not quite sure whether this ‘leave’ detection is a necessity. Until all router host routes are updated by the ‘link-up’ detection that should ensue in a short while, the knowledge of a node having left a specific link might not be of any significant help in retaining the e2e transport connection. Lost packets in the intermittent ‘dark’ period should be recovered by a usual transport operation.

On the other hand, one can also argue that prompt knowledge of a node having left a link should still help if the router implements an additional function of storing the packets destined to the very node until its location be identified by a later link-state update by the router observing the link-up by a visiting node. However, this additional functionality on the part of routers might be too far stretched.

Anyway, before going into any more details, we might first come to a consensus whether tackling again on the issue of multi-link subnet in a form similar to SID6 or any other should be a worthwhile 6man WG work.

Thanks.

---

From: DY Kim <[email-masked]>
Date: Tue, 4 Sep 2018 17:38:03 +0900

> On 4 Sep 2018, at 17:29, DY Kim <[email-masked]> wrote:
> 
> we might first come to a consensus whether

… we might first have to come to ...

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Sep 2018 07:47:38 +1200

> I can think of mosh, but I’m hard pressed to find other good examples.

Well, maybe this is an ART area discussion, but isn't the basic reason
for RESTfulness really that both IP and transport layers are liable to
unexpected disconnects?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Sep 2018 08:04:03 +1200

On 2018-09-04 14:41, Tom Herbert wrote:
> very well adversely impact user experience.

Yes, although I'm not sure the present proposal will fix that problem.
In any case the routing system has to respond very quickly.

> Also, not all applications

Yes, but natural selection will tend to eliminate such apps and devices
if this becomes a common scenario.

> I think the mobile addressing model there is similar to what is being

Sure. You're trading locator bits that have topological significance
against hidden dynamic state in the routing system. It takes me right
back to memories of site-wide bridged networks 25 years ago.

    Brian

> .

---

From: Tom Herbert <[email-masked]>
Date: Tue, 4 Sep 2018 13:15:44 -0700

Brian,

Hopefully, newer applications will properly reconnect when a host is
disconnected and an address goes away, or maybe they are behind an API
that does that transparently for them. Regardless, it's unlikely that
all applications do this properly (there's no requirement that I aware
of as to what they have to do in this case).

But, the bigger is issue is _how_ hosts gets notified so that it knows
addresses have gone away it should close its connections. For a
directly attached device, like a smartphone attached to a cell for
instance, when the link is disconnected the system will detect that
and can remove the addresses and close any connections that are no
longer viable. But, there may also be downstream devices to which the
mobile device delegated addresses (e.g. by DHCP). All of those devices
must be informed somehow that their addresses are no defunct. I assume
there's protocol to do this, like DHCP revoking a lease, but it
doesn't sound super trivial to me to get this right.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 4 Sep 2018 16:03:16 -0700

A few comments:

>From the draft: "This document proposes to change the operation of
IPv6 networking by deprecating the SID.  That is, the value of SID
shall be set to zero."

Specifying that part of the IP address is always zero seems like an
incredible waste of a resource. I think the more compelling idea is
alluded to later (section 3.6) which is for a site to reclaim those
bits to use for other purposes.

I don't follow the description of recursive networking. It sounds like
this either describing hierarchical routing or identifier/locator
separation in addresses somehow.

If I'm reading section 4.3 correctly, mobility happens by host routes
in the routing system. Not sure that can scale. In any case, if this
draft is poposing a new mobility mechansim it probably should be
described in its own draft.

Tom

On Mon, Sep 3, 2018 at 12:51 AM, DY Kim <[email-masked]> wrote:
> Hi,
>
> I’ve reposted a draft, this time to 6man, which was posted to 6ops about a
> year ago but fell out of scope there since it involves some changes to
> NDv6/DAD with added texts.
>
> I’d like to see whether there should be any interest in this draft within
> the 6man group, possibly enough to justify the modification of NDv6/DAD as
> suggested in this draft.
>
> URL:
> https://www.ietf.org/internet-drafts/draft-dykim-6man-sid6-00.txt

---

From: DY Kim <[email-masked]>
Date: Wed, 5 Sep 2018 09:01:42 +0900

in-line.

---
DY

> On 5 Sep 2018, at 08:03, Tom Herbert <[email-masked]> wrote:
> 

Well taken.

Something to note: If the field is used for Unique IPv6 Prefix for Host, then the number of hosts in a site will be limited to 2**16, assuming the site gets /48 from the provider. If it is desired to accommodate more hosts, the site might get a shorter provider prefix, say /32.

> separation in addresses somehow.

In fact, the major motivation for this draft is to provide transport connection resilience without resorting to identifier/locator separation. The draft is not about identifier/locator separation, I’d say.

Description on recursive networking should be more of an academic exploration. The related text, and possibly also other ‘stretched’ academic claims, could be removed to leave only technical essence of the proposal.

> described in its own draft.

The draft starts with saying it is for ‘sites of manageable sizes for which scalability is not much a critical issue.’ The technical idea is to be applied only as far as the scale doesn’t break the system.

I don’t mean to claim the technology would replace the legacy IPv6 operation in a global scale. It is only for those application areas wherein the network owner finds the technology useful for their purposes.

In the era of IoT, there might arise various networks where different application requirements might justify different mode of operation, e.g.,  as suggested by this draft.

---

From: DY Kim <[email-masked]>
Date: Wed, 5 Sep 2018 09:07:09 +0900

---
DY

> described in its own draft.

One more word to this. A new mobility mechanism to propose was not the major intention of the draft. As said, provision of intra-site transport connection resilience without resorting to identifier/locator separation was the main object. In doing that, I just relied on the routing system for intra-site mobility.

---

From: DY Kim <[email-masked]>
Date: Wed, 5 Sep 2018 09:24:55 +0900

---
DY

> Which of one flavous is described in https://tools.ietf.org/html/draft-ietf-ipv6-multilink-subnets-00

On my second thought, I’m not sure whether SID6 is a kind of multi-link subnet, although it might be that the two attempt to achieve similar things.

In SID6, each link bordered by a router is seen as a subnet which, however, is not identified by the Subnet Prefix but by the NID(node ID), i.e., the IP address of the router. In this view, each subnet consists of a single link. If a link is bordered by more than one routers, the link belongs to more than one subnets of which each is identified by a different NID of the associated router.

Sharing /64 across multiple links might be the same for the two. However, if we utilize the subnet prefix (64 - site prefix) for Unique IPv6 Prefix for Host (Sec. 3.6 of SID6), we’re effectively sharing the site prefix across all intra-site nodes.

---

From: David Farmer <[email-masked]>
Date: Thu, 6 Sep 2018 18:43:10 -0500

I'm not sure this is an IP layer problem, v4 or v6, some of it might not be
an IETF problem either. If you want hosts to have the same IP address as it
moves around a site this is possible today with things like 802.1x, you put
the host in the same VLAN whatever port or AP it attaches too. If you are
worried about stretching layer 2 everywhere in a site then look at
abstractions like VXLAN or MPLS with EVPN as your control plane with the
right hardware can scale to extremely large sites. There are other options
too like TRILL, shorted path bridging, even LISP, etc...

Basically, you end up with control plane that has every MAC address, IPv4
/32 and IPv6 /128, probably every IPv4 and IPv6 prefix, and if you are
doing multicast you probably need (S,G) state too. The advantage of this
model it is IP version agnostic and ethernet protocol agnostic.  Further,
this also allows the many simpleton assumptions applications make today
about the network to hold true.

I'm not sure we need an IPv6-only solution in this problem space.

Thanks

On Mon, Sep 3, 2018 at 2:51 AM, DY Kim <[email-masked]> wrote:

> *From: [email-masked]
> *Subject: **New Version Notification for draft-dykim-6man-sid6-00.txt*
> *Date: *3 September 2018 at 16:46:04 GMT+9
> *To: *"DY Kim" <[email-masked]>
>
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: DY Kim <[email-masked]>
Date: Fri, 7 Sep 2018 16:48:46 +0900

Well heard.

---
DY

> On 7 Sep 2018, at 08:43, David Farmer <[email-masked]> wrote:
> 
> I'm not sure this is an IP layer problem, v4 or v6, some of it might not be an IETF problem either. If you want hosts to have the same IP address as it moves around a site this is possible today with things like 802.1x, you put the host in the same VLAN whatever port or AP it attaches too. If you are worried about stretching layer 2 everywhere in a site then look at abstractions like VXLAN or MPLS with EVPN as your control plane with the right hardware can scale to extremely large sites. There are other options too like TRILL, shorted path bridging, even LISP, etc... 
> 
> Basically, you end up with control plane that has every MAC address, IPv4 /32 and IPv6 /128, probably every IPv4 and IPv6 prefix, and if you are doing multicast you probably need (S,G) state too. The advantage of this model it is IP version agnostic and ethernet protocol agnostic.  Further, this also allows the many simpleton assumptions applications make today about the network to hold true.
>

---

From: Brian Haberman <[email-masked]>
Date: Fri, 7 Sep 2018 07:13:27 -0400

There are also mobility-related solutions like PMIP that eliminate the 
host-based complexities of MIP while still allowing the host to maintain 
the same IP address as it moves through the site/enterprise.

---

From: DY Kim <[email-masked]>
Date: Sat, 8 Sep 2018 12:11:15 +0900

---
DY

So, there are...

  - PMIP, 802.x + VLAN, VXLAN or MPLS with EVPN, TRILL, shorted path bridging, LISP, ….

Would it do any fatal harm then to add another to this already long list of alternative solutions?

The arguments seem to me like saying…

  - There are lots of ways to get from place A to B, like trains, trams, buses, gas automobiles, subways, flights, ships, bikes, horses, and so forth, and why do you want to talk about electric cars?

Moreover, all mentioned by David and Brian require infrastructures extra to usual plain customer networks, while SID6 attempts to tackle the problem without introducing such extras, except some updates to ND/DAD which is one of basic building  blocks of legacy IPv6 networking.

Rather, I’d like to see comments like

  - if SID6 is technically viable or not,
  - if SID6 will break in certain situations.

That is, I’d like to see SID6 assessed/criticized in its own technical merits or on serious technical loopholes if any.

> On 7 Sep 2018, at 20:13, Brian Haberman <[email-masked]> wrote:
> 
> There are also mobility-related solutions like PMIP that eliminate the host-based complexities of MIP while still allowing the host to maintain the same IP address as it moves through the site/enterprise.
>