Subject: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt

From: DY Kim <[email-masked]>
Date: Tue, 1 Aug 2017 18:34:55 +0900

Hi,

I’ve drafted a wild idea which might fall uneasy to most list members. My knowledge is rather shallow, the draft might not be free from technical flaws. Your critical comments are welcome.

---
DY

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-dykim-v6ops-sid6-00.txt
> Date: 1 August 2017 at 18:32:04 GMT+9
> To: "DY Kim" <[email-masked]>
> 
> 
> A new version of I-D, draft-dykim-v6ops-sid6-00.txt
> has been successfully submitted by DY Kim and posted to the
> IETF repository.
> 
> Name:		draft-dykim-v6ops-sid6
> Revision:	00
> Title:		Subnet ID Deprecation for IPv6
> Document date:	2017-08-01
> Group:		Individual Submission
> Pages:		18
> URL:            https://www.ietf.org/internet-drafts/draft-dykim-v6ops-sid6-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-dykim-v6ops-sid6/
> Htmlized:       https://tools.ietf.org/html/draft-dykim-v6ops-sid6-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dykim-v6ops-sid6-00
> 
> 
> 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: Tue, 1 Aug 2017 19:12:42 +0900

The subnet ID isn't really much of "a thing" from a protocol
perspective to begin with, so I'm not sure saying this document is
deprecating it is accurate.

This document includes protocol changes, and as such should probably
be run past 6man.

I don't expect it to fair well, as (among other things) I expect
site-local multicast DAD to be...problematic, at best.

I, for one, would oppose this document.  Section 4.7 is especially deplorable.

On 1 August 2017 at 18:34, DY Kim <[email-masked]> wrote:
> Hi,
>
> I’ve drafted a wild idea which might fall uneasy to most list members. My
> knowledge is rather shallow, the draft might not be free from technical
> flaws. Your critical comments are welcome.
>
> ---
> DY
>
>
>
>
> Begin forwarded message:
>
> URL:
> https://www.ietf.org/internet-drafts/draft-dykim-v6ops-sid6-00.txt
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-dykim-v6ops-sid6-00
>
>
> Abstract:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 1 Aug 2017 22:23:57 +0900

> I, for one, would oppose this document.  Section 4.7 is especially deplorable.

Uncalled for; my apologies.  I should simply say "objectionable".

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Aug 2017 07:51:38 -0700

> This document includes protocol changes, and as such should probably

I have just read it. I would agree; it updates RFC 4291, and by extension 4291bis, and should be discussed in the same context. We will need to point 6man at it.

That said, I'd suggest we collect operational viewpoints before we do that. Erik has given his. Other comments on the draft?

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Aug 2017 07:51:45 -0700

> I’ve drafted a wild idea which might fall uneasy to most list members. My knowledge is rather shallow, the draft might not be free from technical flaws. Your critical comments are welcome.

<Hat off>

This draft reminds me of the behavior of DECNET IV, which had systems in "areas" that were potentially discontigous and not on the same LAN, which were then interconnected by intra-area and inter-area routers. Often, every host was configured as an intra-area router, and knew the path to every other host in the area as well as one or more inter-area routers.

When IS-IS was being designed, Digital took its experience in that and designed two layers of routing - host to host (identified by the full NSAP less the final NSEL) within the area, and area to area (using the NSAP less the final NSEL and the Station Part) within the network. Networks (identified by CLNS NSAPs without the last 9 octets) were interconnected by a separate protocol similar to BGP.

So, could this model work? Yes, it could, with the appropriate routing protocol within the network identified by the prefix. Could it scale? I would think that Digital's experience was that it could, with appropriate operational management of the network to make that happen.

That said, such a change would be a fairly violent change to the structure of an IPv6 network. ND Host Solicitation and Announcement as currently designed is mostly-pointless, and has to be replaced by something conceptually similar to the intra-area level of IS-IS, using one of several algorithms, and potentially different algorithms in different areas. It changes the address from the address of an interface to the address of a host - which is not automatically a bad idea (and for many hosts is perhaps not even a change), but is different and needs to be thought through.

So from my perspective, this might be an interesting experiment, but I couldn't recommend it for general deployment absent the supporting routing work.

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 07:23:50 +0900

> On 1 Aug 2017, at 19:12, Erik Kline <[email-masked]> wrote:
> 
> perspective to begin with

Really? I think Subnet ID is what makes IPv6/IPv6 peculiar enough to differentiate their networking paradigm from other architectures, and that in a negative sense, at least to me.

> This document includes protocol changes, and as such should probably

I’m not that far to ask ‘change’ the protocols. For now, I’m just seeking opinions from the operators or users of the IPv6 networking… whether it’s any idea to pursue further or is just another trash to throw right away.

Only when there’d be some encouraging support for the trial, bringing the material to 6man would make any sense, I’d think.

> I expect

Here’s where technical debate might be in place…

> I, for one, would oppose this document.

OK, got your opinion.

>  Section 4.7 is especially deplorable.

Regretful.

- DY -

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 07:31:06 +0900

> On 1 Aug 2017, at 23:51, Fred Baker <[email-masked]> wrote:
> 
> I have just read it. I would agree; it updates RFC 4291, and by extension 4291bis, and should be discussed in the same context.

I’m afraid, not yet. RFC 4292 is the heart of IPv6, and trying to change it before any strong consensus is built first would not be a good idea.

Also, I tried not to mean direct change of RFC 4291 (or -bis) but just different ‘operational choice’ or ‘interpretation’ of that base standard.

If any, changes would be on ND and DAD, not directly on RFC 4291.

> That said, I'd suggest we collect operational viewpoints before we do that.

That’s exactly what I’d be seeking at this stage.

Thanks.

- DY -

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 08:01:51 +0900

> This draft reminds me of the behavior of DECNET IV, which had systems in "areas" that were potentially discontigous and not on the same LAN, which were then interconnected by intra-area and inter-a…

In SID6, not every host is configured as a router. Some of the hosts form a subnet (as usual, albeit with no extra explicit subnet ID) managed by a DR. For communication with off-link hosts, the hosts in the subnet would rely on the DR for relaying.

> That said, such a change would be a fairly violent change to the structure of an IPv6 network.

Indeed, effectively… That’s why I said ‘wild’.

> It changes the address from the address of an interface to the address of a host.

This is exactly the core of my proposal, which I’m afraid might be too hard/harsh for IP networking advocates to easily accept, I’m afraid.

But, were the IP address not the interface address but the node address, would there have been such a hype or need for identifier/locator separation efforts? What I wanted to show is that, if the address points to the node (not to the interface), the problem space of the identifier/locator separation could have been a non-problem at least within a site.

.. and what about the inter-site (inter-AS) mobility? We could live with MIPv6 for that, since infrastructure-less e2e connection resilience in that case would not be a compelling requirement for most networking.

To be put in another way, I’m trying to say that IPv6 is just fine and very fine only if the address is the node address. It doesn’t need to be exposed to attacks by identifier/locator advocates. Any identifier/locator proposals add substantial extra infrastructure/complexity to IPv6 networking, and for that are almost equivalent to change the whole of native IPv6 networking. My ‘wild’ proposal for node address might not be as destructive to the native IPv6.

This is the message I’m trying to deliver.

> So from my perspective, this might be an interesting experiment, but I couldn't recommend it for general deployment absent the supporting routing work.

Although my document comments on protocol (ND and DAD) changes and deployability, that’s not my intention to push too early for that direction. All that material is just to demonstrate the technical feasibility/implementability of my proposal, if people might want that direction.

All I’m seeking now at this stage is to see whether there’d be any experts in the field who would find any bit of value in the proposal and would be ready for ‘experimental’ exploration.

I’m not yet proposing any serious action.

- DY -

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Aug 2017 18:42:04 -0700

> On Aug 1, 2017, at 3:31 PM, DY Kim <[email-masked]> wrote:
> 

Well, again hat off, I think you didn't succeed. If devices are on interfaces, ND (which is designed around shared LANs and therefore interfaces) works. If devices simply "somewhere in a network" and the network is other than trivial, you need something a lot more than ND, something a lot more like IS-IS (although the algorithm could differ, and could be different in various parts of the same network). We're in the process of taking RFC 4291 to Internet Standard, which implies "no changes other than removing features not proven interoperable". That's not an "interpretation".

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 Aug 2017 07:55:03 +0200 (CEST)

> So from my perspective, this might be an interesting experiment, but I couldn't recommend it for general deployment absent the supporting routing work.

I've seen proposals that have intersection with this proposal. There was 
work to support L3 mobility in for instance a home (by injecting host 
routes in the home IGP) as devices moved between L3 wifi APs.

The whole proposal about whole /64 per host so this can be moved around 
also touches on areas close to this I-D. Here the entire /64 to a host is 
a similar idea that doesn't mean anything needs to change in the host.

IS-IS and ES-IS has the interesting property of the end systems basically 
"registering" their addresses with the router, meaning the router doesn't 
have to do discovery. It already knows the systems on the wire. If we 
disregard "quiet systems", IPv6 also has this (there have been proposals 
that routers should not initiate ND, but instead rely on systems being 
alive and talking to the router so ND table is always populated).

I-D-sid6 seems to propose moving addresses around. This is not compliant 
with RFC7934 (Host Address Availability Recommendations). However, 
combining things like I-D-unique-ipv6-prefix-per-host with 
I-D-pioxfolks-6man-pio-exclusive-bit with probably some other mechanism we 
don't have yet, we would gain "fast attach" with stable prefix to assign 
addresses out of. If we're moving prefixes around then we need to somehow 
be sure that the attaching party is actually who they claim to be, and we 
need them to start communicating very quickly after attachment. The 1s DAD 
delay is one problem in this that the PIO-X bit "fixes".

What I'd like to see is a way to very quickly attach and start 
communicating. Brainstorming list of events:

Device attaches to AP.
Device sends some kind of cryptographic identifier/token/certificate 
saying "trust me based on this, I have this address"
Router/AP checks certificate
If accepted, install route towards MAC address of device. This route is 
then flooded in the IGP as well.
Router sends RA (or something else), indicating that host now can use 
those addresses

Device then periodically renews this cryptographic information somehow.

I believe this can mean we have really really fast attachment of devices 
as they move around. I don't think we can make this work quickly enough if 
it involves RS, RA, DAD, DHCPv6 questions, ND lookups etc. It would also 
mean devices would have prefixes moved around, not addresses.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 16:13:45 +0900

In line…

---
DY

> On 2 Aug 2017, at 10:42, Fred Baker <[email-masked]> wrote:
> 
> Well, again hat off, I think you didn't succeed. If devices are on interfaces, ND (which is designed around shared LANs and therefore interfaces) works. If devices simply "somewhere in a network" and the network is other than trivial, you need something a lot more than ND, something a lot more like IS-IS (although the algorithm could differ, and could be different in various parts of the same network).

Perhaps, something like ES-IS…?

> We're in the process of taking RFC 4291 to Internet Standard, which implies "no changes other than removing features not proven interoperable". That's not an "interpretation”.

OK… too late… ha..?

BTW, it was a surprise to me that RFC 4291 is not yet an Internet Standard, after all those 20 years… interesting.

So, ideas like mine have to die or wait for the next round refreshing (if any) of RFC 4291…?

One thing I’m concerned about (with no good reason?) is the proliferation of identifier/locator separation protocols. On top of that, people now even start adding a layer of ‘identity’ (IDEAS BoF).

Are these patchings the absolute inevitable? Couldn’t we thrive just with native IPv6 and DNS for all those only if we tweak a little bit on IPv6? Aren’t those patches going to make much of IPv6 irrelevant as NAT did about IPv4?

Regretful...

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 16:30:36 +0900

Hi Mkikael,

Your idea of certificate should be a good idea.

But, I’d be curious why you think it would not work for moving addresses?

For example, in the basic mode of SID6, all intra-site nodes would share the same prefix assigned to the site; say, this is 64-bits, without losing generality. Each node would then register itself with the router (with certificate) informing its node ID of 64 bits.

When a node leaves its original subnet (or LAN) and attaches to another router in the site, it would report its node ID (also repeating the common prefix if appropriate) with the certificate to the visited router. With the certificate verified, the new router would right away acknowledge the successful attachment and would flood an associated link update.

Of course, the similar scenario works if the granularity is not the node ID (effectively address) but the prefix. But again, there should no no reason why the same scenario should not work for the granularity of address.

---
DY

> On 2 Aug 2017, at 14:55, Mikael Abrahamsson <[email-masked]> wrote:
> 
> It would also mean devices would have prefixes moved around, not addresses.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 Aug 2017 10:02:51 +0200 (CEST)

> But, I’d be curious why you think it would not work for moving 

It works to move around addresses, it's just that best common practice is 
that a device should have lots of addresses. Seems more efficient to have 
a prefix to the device instead, not addresses.

> For example, in the basic mode of SID6, all intra-site nodes would share 
> the same prefix assigned to the site; say, this is 64-bits, without 
> losing generality. Each node would then register itself with the router 
> (with certificate) informing its node ID of 64 bits.

Then it would just have a single address, which would not follow RFC7934 
(BCP204).

I'm not saying it would not work, it's just not what we should do.

If you told me the site has a /48, a 64 bit node ID, and each host now 
gets a /112, this would not go against RFC7934.

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 17:15:03 +0900

in line..

---
DY

> On 2 Aug 2017, at 17:02, Mikael Abrahamsson <[email-masked]> wrote:
> 
> It works to move around addresses, it's just that best common practice is that a device should have lots of addresses.

> Then it would just have a single address, which would not follow RFC7934 (BCP204).

I was not properly attentive to RFC 7934. I do agree to moving prefix.

Thanks for the pointer.

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 17:34:11 +0900

I’m lost at your /112. Did you mean something like:

	site prefix: /48
	node prefix: /64
	node ID: 64 bits (can generate multiple 64-bit NIDs per prefix /64).

This arrangement would accommodate 2**16 nodes in a site.

If one would like to have two-level routing for routing scalability, then the 16 bits can be sliced like, e.g.,:

	site prefix: /48
	area prefix: /48+n
	node prefix: /64-n
	node ID: 64 bits

, with n =< 16.

---
DY

> If you told me the site has a /48, a 64 bit node ID, and each host now gets a /112, this would not go against RFC7934.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 Aug 2017 10:46:17 +0200 (CEST)

> If one would like to have two-level routing for routing scalability, then the 16 bits can be sliced like, e.g.,:

No, I meant site prefix /48, node ID 64 bits, node prefix 16 bits.

I could live with cutting down the node ID size as well.

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 17:47:09 +0900

Got it.

---
DY

> On 2 Aug 2017, at 17:46, Mikael Abrahamsson <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 17:59:52 +0900

In the scenario we’re talking about (in which others in the list might not be interested), considering that privacy is more with the node prefix than with the node ID, a better arrangement could be:

	site prefix: /48
	node prefix: /112
	node ID: 16 bits

Obfuscation of the node prefix is the order of 2**64 while each node can have addresses (node IDs) as many as 2**16 (too many?).

---
DY

> On 2 Aug 2017, at 17:47, DY Kim <[email-masked]> wrote:
> 
> Got it.
> 
> ---
> DY
>

---

From: "Russ White" <[email-masked]>
Date: Wed, 2 Aug 2017 07:47:11 -0400

> I have just read it. I would agree; it updates RFC 4291, and by extension
> 4291bis, and should be discussed in the same context. We will need to point
> 6man at it.
> 
> Erik has given his. Other comments on the draft?

I've just read this, and several (possibly incorrect) thoughts... So take them with a grain of salt. 

Essentially, this seems to entail host routing at the site level, unless you do something like the original IS-IS level 2 with attached bit to level 1's. This is actually okay/a good thing in many environments at the site level. I think we way overblow the problems or running a lot of prefixes in an IGP -- we've moved from 10-15 views of 100k routes being "big" in 1996 to 200-250 views of 1.5 million routes being "big" today (though I think there might be speakers with more). And yet, we still have a minor heart attack when someone suggests we should be able to carry 250k routes in EIGRP or IS-IS -- in fact, I've seen both done quite well, and the open fabric work is specifically targeted at 250-300k routes across 5k'ish nodes in a single flooding domain in a variant of IS-IS. We seem to have upped our impression of BGP incrementally without noticing, and not thought through the implications on the IGP side. In fact, doing something like this could get rid of much of the "let's stretch layer 2 for the one millionth time in yet another creative (and probably harmful) way" we seem to be experiencing right now. Good riddance, I would say -- stretched layer 2 is an abomination that has been much more harmful than port NAT ever was.

On the other hand, there are some places where you don't want to host route, I think. Per link aggregation is still a good thing in many cases. There are a range of solutions you could probably deploy to solve this sort of problem -- for instance, you could solve this by treating such situations as a single level 1 flooding domain from the link state's perspective, a strange land where all the hosts expect addresses with the same prefix to be on the same broadcast domain, because the hosts don't support the requisite protocols. This would be useful in a lot of situations, so this is something that would definitely need to be looked in to and solved. For instance, no-one is (probably) going to develop and deploy a host routing stack like ES-IS for mobile devices (mobile phones, tablets, etc.).  

There are some quibbles with this, however. The first is that we don't need to set the SID to 0 to do any of this -- in fact, it seems like a waste of good address space to do so. I know it feels like the IPv6 address space is infinite right now, but it's really not. We need to be careful here. IS-IS can provide a good analog here, as well. There are two parts to the upper bits of the address, the HO-DSP and the area. These are treated as one "thing" by every IS-IS deployment I know of, and have been for years. Just eliminate the SID, rather than setting it to 0. Push those bits into some other part of the address where they will work for both possible deployment models.

The second is this --

==
When a site is multihomed on multiple upstream networks, it would be associated with multiple site prefixes and hence every intra-site node would be associated with multiple addresses.  For seamless site-multihoming in such an instance, a node should be able to receive inbound packets destined to any of its multiple addresses, and also be able to source outbound packets with one of such multiple   addresses as appropriate [DASv6].
==

This is not a bad thing per se, but there is a configuration issue here that needs to be addressed. Specifically, you cannot have partitions within any upper bits of address space if you play this game. The results are very bad. So this would need to be thought through, etc.

On the routing side, I'm perfectly willing to work on a draft of a protocol to solve the routing parts of this problem... Building a small, lightweight protocol to gather local routing information for a host, is very close to the MANET space; I can think of some folks who would be really interested in working on such a thing from a research perspective. If you combined such a thing with dynamic DNS (think ILNP), you get lots more host mobility out of this sort of thing, as well, so there is some thought that needs to be put in, in that direction.

I would argue against doing anything with a tunneled overlay or overlay routing protocol here -- I would rule that out from the first day of work. Tunneled solutions are possible, but different; we're addicted to overlays right now, it would be good to solve something without a tunneled header for once. 😊

So my initial thoughts are -- interesting, a lot more work than it looks like, a lot of uphill battles, probably ultimately useful in at least some environments, but we need to be careful to consider environments where this would not be useful.

😊

Russ

---

From: DY Kim <[email-masked]>
Date: Wed, 2 Aug 2017 21:07:00 +0900

Hi Russ,

Thanks for your comments.

Two things:

[Russ] “Just eliminate the SID, rather than setting it to 0. Push those bits into some other part of the address where they will work for both possible deployment models.”

[DY] I agree. I started with nullifying it to be consistent with the current IPv6 addressing model. But, just killing it and assign the bits to either eastwards or westwards would be better. The idea of node prefix as Mikael suggested would be an idea, too.

[Russ] "a lot more work than it looks like, a lot of uphill battles, probably ultimately useful in at least some environments, but we need to be careful to consider environments where this would not be useful.”

[DY] I fully agree. After all, I’m not such an expert in IPv6 networking realities, so, in every pushing the idea forwards, it is essential that real experts chip (jump) in to come up with neat solutions. My trial in the draft should be too clumsy. As long as the core message (on which I commented in a response to Fred) of mine would be taken, I would be wholly open to expertise contributions or takeover.

Thanks.

---
DY

> On 2 Aug 2017, at 20:47, Russ White <[email-masked]> wrote:
> 
>

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 20:30:41 +0900

Based on a conversation with John Brzozowski in the thread on ‘unique ipv6 prefix per host’, I’d say most of SID6 is pursuing could be achieved by appropriate application of that draft to a site of interest:

  o Every intra-site node would be assigned a /64 prefix from a central prefix pool installed somewhere (preferably at the site border router) in the site.

  o With the use of 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07’, there’d be no need for ND and DAD, and hence no changes to previous protocols are necessary.

  o All that remains is that the IGP now deals with host prefix routes throughout.

  o In that fashion, intra-site node mobility is provided inherently by the IGP.

  o Behaviors of the site exposed to DFZ remain the same as with usual legacy sites, so such a site can be deployed incrementally, not disturbing the DFZ.

I’m happy with 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07’.

--------
Regards,
DY

< quote begins >

On 4 Aug 2017, at 19:25, Brzozowski, John <[email-masked]> wrote:

As long as the router facing the end points is able to transmit a unique prefix per host in the RA then both of the cases below will work.

John
+1-484-962-0060

From: v6ops <[email-masked]> on behalf of DY Kim <[email-masked]>
Date: Thursday, August 3, 2017 at 21:39
To: v6ops <[email-masked]>
Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

In the 2nd para of Sec. 4, it reads:

"The Unique IPv6 prefix can be derived from a locally managed
  pool or aggregate IPv6 block assigned to the First Hop Provider
  Router or from a centrally allocated pool.”

In the case the prefix is assigned from a centrally allocated pool, does this scenario include the following cases?:

o all prefixes assigned to devices on the same shared network may not be aggregatable into a single shorter prefix.
o /64 prefixes may be assigned randomly to different devices on different share network.

—
DY

< quote ends >

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 22:04:26 +0900

The unique prefix per host is /64. Hence, when a site is assigned a /48 prefix as usual, as many as 64K (2**16) nodes can be accommodated, which number being not terribly huge but large enough for most application cases, I’d think.

--------
Regards,
DY

> On 4 Aug 2017, at 20:30, DY Kim <[email-masked]> wrote:
>

---

From: Truman Boyes <[email-masked]>
Date: Fri, 04 Aug 2017 14:01:42 +0000

I am happy to see creative proposals such as this draft. But I do question
the environment where this technology would ideally live. I see very little
interest within the DC to support address mobility from the network. There
are plenty of ways to solve mobility of a service if we do care about the
significance of the address.

Truman

On Wed, Aug 2, 2017, 08:07 DY Kim <[email-masked]> wrote:

> [Russ] “Just eliminate the SID, rather than setting it to 0. Push those
> bits into some other part of the address where they will work for both
> possible deployment models.”
>
> [DY] I agree. I started with nullifying it to be consistent with the
> current IPv6 addressing model. But, just killing it and assign the bits to
> either eastwards or westwards would be better. The idea of node prefix as
> Mikael suggested would be an idea, too.
>
> [Russ] "a lot more work than it looks like, a lot of uphill battles,
> probably ultimately useful in at least some environments, but we need to be
> careful to consider environments where this would not be useful.”
>
> [DY] I fully agree. After all, I’m not such an expert in IPv6 networking
> realities, so, in every pushing the idea forwards, it is essential that
> real experts chip (jump) in to come up with neat solutions. My trial in the
> draft should be too clumsy. As long as the core message (on which I
> commented in a response to Fred) of mine would be taken, I would be wholly
> open to expertise contributions or takeover.
>
> Thanks.
>
> ---
> DY
>
>
>
>
>
>
> > Essentially, this seems to entail host routing at the site level, unless
> you do something like the original IS-IS level 2 with attached bit to level
> 1's. This is actually okay/a good thing in many environments at the site
> level. I think we way overblow the problems or running a lot of prefixes in
> an IGP -- we've moved from 10-15 views of 100k routes being "big" in 1996
> to 200-250 views of 1.5 million routes being "big" today (though I think
> there might be speakers with more). And yet, we still have a minor heart
> attack when someone suggests we should be able to carry 250k routes in
> EIGRP or IS-IS -- in fact, I've seen both done quite well, and the open
> fabric work is specifically targeted at 250-300k routes across 5k'ish nodes
> in a single flooding domain in a variant of IS-IS. We seem to have upped
> our impression of BGP incrementally without noticing, and not thought
> through the implications on the IGP side. In fact, doing something like
> this could get rid of much of the "let's stretch layer 2 for the one
> millionth time in yet another creative (and probably harmful) way" we seem
> to be experiencing right now. Good riddance, I would say -- stretched layer
> 2 is an abomination that has been much more harmful than port NAT ever was.
> >
> > On the other hand, there are some places where you don't want to host
> route, I think. Per link aggregation is still a good thing in many cases.
> There are a range of solutions you could probably deploy to solve this sort
> of problem -- for instance, you could solve this by treating such
> situations as a single level 1 flooding domain from the link state's
> perspective, a strange land where all the hosts expect addresses with the
> same prefix to be on the same broadcast domain, because the hosts don't
> support the requisite protocols. This would be useful in a lot of
> situations, so this is something that would definitely need to be looked in
> to and solved. For instance, no-one is (probably) going to develop and
> deploy a host routing stack like ES-IS for mobile devices (mobile phones,
> tablets, etc.).
> >
> > There are some quibbles with this, however. The first is that we don't
> need to set the SID to 0 to do any of this -- in fact, it seems like a
> waste of good address space to do so. I know it feels like the IPv6 address
> space is infinite right now, but it's really not. We need to be careful
> here. IS-IS can provide a good analog here, as well. There are two parts to
> the upper bits of the address, the HO-DSP and the area. These are treated
> as one "thing" by every IS-IS deployment I know of, and have been for
> years. Just eliminate the SID, rather than setting it to 0. Push those bits
> into some other part of the address where they will work for both possible
> deployment models.
> >
> > The second is this --
> >
> > ==
> > When a site is multihomed on multiple upstream networks, it would be
> associated with multiple site prefixes and hence every intra-site node
> would be associated with multiple addresses.  For seamless site-multihoming
> in such an instance, a node should be able to receive inbound packets
> destined to any of its multiple addresses, and also be able to source
> outbound packets with one of such multiple   addresses as appropriate
> [DASv6].
> > ==
> >
> > This is not a bad thing per se, but there is a configuration issue here
> that needs to be addressed. Specifically, you cannot have partitions within
> any upper bits of address space if you play this game. The results are very
> bad. So this would need to be thought through, etc.
> >
> > On the routing side, I'm perfectly willing to work on a draft of a
> protocol to solve the routing parts of this problem... Building a small,
> lightweight protocol to gather local routing information for a host, is
> very close to the MANET space; I can think of some folks who would be
> really interested in working on such a thing from a research perspective.
> If you combined such a thing with dynamic DNS (think ILNP), you get lots
> more host mobility out of this sort of thing, as well, so there is some
> thought that needs to be put in, in that direction.
> >
> > I would argue against doing anything with a tunneled overlay or overlay
> routing protocol here -- I would rule that out from the first day of work.
> Tunneled solutions are possible, but different; we're addicted to overlays
> right now, it would be good to solve something without a tunneled header
> for once. 😊
> >
> > So my initial thoughts are -- interesting, a lot more work than it looks
> like, a lot of uphill battles, probably ultimately useful in at least some
> environments, but we need to be careful to consider environments where this
> would not be useful.
> >
> > 😊
> >
> > Russ
> >

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 02:36:33 +0900

Yes, there are plenty of ways to solve intra-site mobility.

With SID6,

	- Intra-site mobility can be provided without extra infrastructure installed due to like MIPv6 and/or any LISs.

	- Inter-site mobility would be provided by MIPv6 as usual.

        - No need to resort to LISs; no id/loc mapping servers and the like.

	- IPv6 networking remains as native (simple) as possible, with no significant extra infrastructure like LISs.

	- ‘Simple is the best.'

--------
Regards,
DY

> On 4 Aug 2017, at 23:01, Truman Boyes <[email-masked]> wrote:
> 
> I am happy to see creative proposals such as this draft. But I do question the environment where this technology would ideally live. I see very little interest within the DC to support address mobility from the network. There are plenty of ways to solve mobility of a service if we do care about the significance of the address.
> 
> Truman

---

From: Simon Hobson <[email-masked]>
Date: Sat, 5 Aug 2017 11:06:40 +0100

> The unique prefix per host is /64. Hence, when a site is assigned a /48 prefix as usual, as many as 64K (2**16) nodes can be accommodated, which number being not terribly huge but large enough for…

That's assuming the entire /48 is allocated to the one network segment.
Suppose the business customer has several sites - that would take several bits off that. And each site might have multiple networks - eg "secure" systems (servers), staff, visitors, IoTs, ... which will need several bits.

You could now be down to a fairly small pool or prefixes for a given network - and given previous comments would make tacking of individual systems a lot easier if an attacker knows that this is the system in use. Ie, an attacker could just ignore the last 64 bits of the address, and then the last (say) 8 bits of the address is now the identifier for the individual host.

So suddenly, you (IIRC) previous suggestion that allocating a (say) /96 to leave more bits for the host identifier, thus making a larger pool for it to be randomised into, would make sense. And there we were (or I was), only moments ago reading about how 64 bits made such an enormous range that we could not possibly run out even with idea not yet thought of - yet here we are, already discussing how restrictive it could be !

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 22:06:29 +0900

I stepped back since it was argued that I cannot escape from the operational practice of /64 prefix and an IID of 64 bits; that the mentioning of /64 in ‘unique prefix per host’ doc is not just an example but almost a MUST.

Of course, I’d be happier if I’m given more freedom in placing the boundary between prefix and IID. If allowed, my preference would be

 /48 site prefix
 /96 host prefix
 32-bit IID

---
DY

> On 5 Aug 2017, at 19:06, Simon Hobson <[email-masked]> wrote:
> 
> So suddenly, you (IIRC) previous suggestion that allocating a (say) /96 to leave more bits for the host identifier, thus making a larger pool for it to be randomised into, would make sense.

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 22:10:31 +0900

By now, I myself am lost in the air with my own reasoning…. Well, …

In a while, I might sit down and give more thought in revising SID6 based on the doc ‘unique prefix per host’.

---
DY

> On 5 Aug 2017, at 22:06, DY Kim <[email-masked]> wrote:
>