Subject: [5gangip] New Version Notification for draft-vonhugo-5gangip-ip-issues-01.txt

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 13 Nov 2016 18:09:26 -0600

A new version of I-D, draft-vonhugo-5gangip-ip-issues-01.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-vonhugo-5gangip-ip-issues
Revision:       01
Title:          Review on issues in discussion of next generation
converged networks (5G) from an IP point of view
Document date:  2016-11-13
Group:          Individual Submission
Pages:          14
URL:
https://www.ietf.org/internet-drafts/draft-vonhugo-5gangip-ip-issues-01.txt
Status:
https://datatracker.ietf.org/doc/draft-vonhugo-5gangip-ip-issues/
Htmlized:       https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-vonhugo-5gangip-ip-issues-01

Abstract:
   This document presents considerations related to open and upcoming
   issues with upcoming new communication systems denoted as 5G aiming
   to set a basis for documenting problem space, use-cases, and
   potential solutions related to next-generation network
   infrastructure.  The draft reviews currently investigated topics,
   including both inputs from IETF and from other SDOs as well as
   research activities.  Further the outcome of recent discussions at
   side sessions during IETF meetings are recaptured to help identifying
   a starting point for future thoughts.

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: Ca By <[email-masked]>
Date: Mon, 14 Nov 2016 14:54:01 +0000

This is a helpful document, but i may be wrong, but i do not believe ILNP
requires any change to the LTE core network and it does not require a
translation function at all.

For me, the major upside in ILNP is that it is a purely host based e2e
solution. So, the impacts of ILNP are strictly isolated to the host and
DNS.

ILNP is a nice fit for 5G since 5G hosts modifications are clearly in scope
for 5G and ILNP solves mobility issue, so the 5G core can be much simpler
since it does not need to track mobility of a user.... this is all handled
in the UE... and becomes a massive simplification since the 5G core only
needs to authenticate and attach the user ...not manager user mobility
state. No tunnel. No nat.

ILNP is the only solution that does not introduce a new box, and it is the
only solution that meaningfully reduces state in the operator network.

I would also not characterize ILA as an upgrade to ILNP. Adding a NAT is
just a different implementation, not an upgrade.

On Sun, Nov 13, 2016 at 4:09 PM Behcet Sarikaya <[email-masked]>
wrote:

> Htmlized:
> https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-01
> Diff:
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 15 Nov 2016 08:07:44 +0900

> ILA does not require a new box. It can run in hosts like ILNP _or_ in the
network more like NAT. This achieves a more flexible solution. Also
different from  ILNP is that ILA is transport layer agnostic so it will
work with any transport layer protocol not just a limited set of supported
transport.

By the way, I still have been unable to find any source code for ILNP. If
anyone knows where I might be able to find that please let me know. Without
an implementation it's really difficult to evaluate it as a potential
solution.

Thanks,
Tom

---

From: Ca By <[email-masked]>
Date: Mon, 14 Nov 2016 23:50:13 +0000

Tom,

To achieve the mobility required in 5G, the usecase requires a NAT, no?

CB

On Mon, Nov 14, 2016 at 3:07 PM Tom Herbert <[email-masked]> wrote:

> ILNP is a nice fit for 5G since 5G hosts modifications are clearly in
> scope for 5G and ILNP solves mobility issue, so the 5G core can be much
> simpler since it does not need to track mobility of a user.... this is all
> handled in the UE... and becomes a massive simplification since the 5G core
> only needs to authenticate and attach the user ...not manager user mobility

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 14 Nov 2016 18:39:00 -0600

Hi Cameron,

Thanks for initiating this discussion.
I used the arguments here in my slides for today's side meeting.

Regards,
Behcet

On Mon, Nov 14, 2016 at 5:50 PM, Ca By <[email-masked]> wrote:
>>> solution. So, the impacts of ILNP are strictly isolated to the host and DNS.
>>>
>>>
>>> ILNP is the only solution that does not introduce a new box, and it is
>>> the only solution that meaningfully reduces state in the operator network.
>>>
>> different from  ILNP is that ILA is transport layer agnostic so it will work
>> with any transport layer protocol not just a limited set of supported
>> transport.
>>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 15 Nov 2016 14:13:08 +0900

> To achieve the mobility required in 5G, the usecase requires a NAT, no?
Hi Ca,

I'm not exactly sure what you mean by NAT in this context. Both ILNP and
ILA are a type of NAT in that the destination address that host sends to is
be translated to a another address for transit across the network. So in
either case, if someone is sending to a mobile host then translation needs
to be done somewhere in the path. In ILNP this can only be done in the
source host, in ILA this can be done either in hosts or devices in the
network. The latter case would be difficult to eliminate. Consider a random
host on the Internet (does not support ILA or ILNP) sends a  packet to a
mobile host. Somewhere in the path the packet needs to be transformed so it
gets to the proper physical location (true for ILA, ILNP, LISP, etc.). This
forwarding node is in the network not at the source host. ILNP is designed
to be end-2-end so this doesn't work natively; I believe there may have
been some discussion of ILNP proxies to provide this functionality. I found
a thread on IRTF RRG on the topic of why ILNP is impractical due to
requirements for changing hosts:
http://www.irtf.org/pipermail/rrg/2008-November/000169.html.

Tom

CB

---

From: Ca By <[email-masked]>
Date: Tue, 15 Nov 2016 09:30:54 -0800

Tom,

On Mon, Nov 14, 2016 at 9:13 PM, Tom Herbert <[email-masked]> wrote:

> network. The latter case would be difficult to eliminate.
>

Very good point. The ILNP opportunity i see is to eliminate the middle
box.  As where ILA (and LISP) requires the middle box to be the anchor
point for mobility, right?  These anchor points are frequently magnets for
operational failure as well as surveillance.

> Consider a random host on the Internet (does not support ILA or ILNP)
> sends a  packet to a mobile host. Somewhere in the path the packet needs to
> be transformed so it gets to the proper physical location (true for ILA,
> ILNP, LISP, etc.). This forwarding node is in the network not at the source
> host. ILNP is designed to be end-2-end so this doesn't work natively; I
> believe there may have been some discussion of ILNP proxies to provide this
> functionality. I found a thread on IRTF RRG on the topic of why ILNP is
> impractical due to requirements for changing hosts:

Also a good point, i get focused on the end game and forget this important
point.  But just like 464XLAT / NAT64, ILNP provides incentive for  an
ideal future where proxy / middle box is removed and proper e2e principles
push mobility into the host.  We could also see a future where 3GPP GTP
based mobility is kept in place for IMS network slice but ILNP is used for
best effort internet slice.

The transition i have in mind, we already see  with NAT64 today.  The
whales (google, facebook, netflix) have move to IPv6, and IPv4 is
legitimately a minority and waning protocol.  The same future is my hope
for ILNP.  The ILNP proxy is a temporary shim that moves out of path as
more folks adopt it... Or simple IPv6 is provided, and ILNP type mobility
services are invoked when negotiated e2e or via proxy.  Services that
benefit from ILNP will deploy those features.

Regards,
Cameron

>>> This is a helpful document, but i may be wrong, but i do not believe
>>> ILNP requires any change to the LTE core network and it does not require a
>>> ILA does not require a new box. It can run in hosts like ILNP _or_ in
>>> the network more like NAT. This achieves a more flexible solution. Also
>>> By the way, I still have been unable to find any source code for ILNP.
>>> If anyone knows where I might be able to find that please let me know.
>>> Without an implementation it's really difficult to evaluate it as a
>>> potential solution.
>>>
>>> Thanks,
>>> Tom
>>>
>>>

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 15 Nov 2016 22:34:31 +0000

Hello, Tom et al.

On 15 Nov 2016, at 05:13, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Nov 15, 2016 at 8:50 AM, Ca By <[email-masked]<mailto:[email-masked]>> wrote:
Tom,

Hi Ca,

I'm not exactly sure what you mean by NAT in this context. Both ILNP and ILA are a type of NAT in that the destination address that host sends to is be translated to a another address for transit across the network.

ILNP is not a type of NAT. ILNP "addresses" (actually identifier-locator vectors - I-LVs) do not need to be translated.

ILNP can, optionally, support Locator Rewriting, but that is not required for the normal operation of ILNP, and even when Locator Rewriting is used, end-to-end state for transport protocols is persevered.

So in either case, if someone is sending to a mobile host then translation needs to be done somewhere in the path. In ILNP this can only be done in the source host, in ILA this can be done either in hosts or devices in the network. The latter case would be difficult to eliminate. Consider a random host on the Internet (does not support ILA or ILNP) sends a  packet to a mobile host. Somewhere in the path the packet needs to be transformed so it gets to the proper physical location (true for ILA, ILNP, LISP, etc.). This forwarding node is in the network not at the source host.

I agree that a non ILA/ILNP/LISP node communicating with a ILA/ILNP/LISP node would require some sort of middlebox.

With an ILNPv6 host (ILNPv6 is ILNP implemented as a superset of IPv6), if that host detects communication being initiated from an IPv6 node, the ILNPv6 node would switch to IPv6.

I do not believe that the scenarios for ILNPv6/IPv6 interoperation have been explored, but I am happy to be proved wrong.

ILNP is designed to be end-2-end so this doesn't work natively; I believe there may have been some discussion of ILNP proxies to provide this functionality. I found a thread on IRTF RRG on the topic of why ILNP is impractical due to requirements for changing hosts: http://www.irtf.org/pipermail/rrg/2008-November/000169.html.

Certainly, the ILNP architectural design was aimed to honour the end-to-end principle. However, that single email (from Nov 2008), I believe does not really capture the whole discussion well.

I think a good summary of the relative pros and cons for ILNP and LISP are summarised in RFC6115 (from Feb 2011, Section 2 for LISP, Section 12 for ILNP). Of course, that predates ILA, and also the state of both ILNP and LISP will have moved on since the publication for RFC6115, but I think the core discussion is still fair.

To implement ILNPv6, updates are required as follows:

a) updates to the host/OS stacks (e.g. OS kernels)
b) updates to getaddrinfo(3)/libc, and additions to /etc/hosts
c) updates to getaddrinfo(3)/libc to allow access to the RFC6742 DNS RRs for ILNPv6
(RFC6742 for the new ILNP DNS RRs is currently implemented by BIND, KnotDNS, and Unbind, I believe)

In terms of whether end host updates are practical, I believe they are - host updates roll out regularly for most modern OSs, including for mobile devices.

Regarding a comment in a previous email about public (non-)availability of code for ILNP, that is a fair point, and something I am working on. I have some code for Linux kernel v3.9.0 -- implementing items a) and b) above -- but it needs to be tidied up and moved across to a more modern Linux kernel version -- as well as being modified for item c) above. The aim is to get the code into one of the main upstream Linux kernel versions as soon as I can (which will be sometime in 2017).

In terms of your comment on evaluation, I am not sure if your intention is to inspect the structure/engineering of the code, or to evaluate its operation and performance. If it is the latter, there are various papers at:

  http://ilnp.cs.st-andrews.ac.uk

Some evaluation of UDP and mobility with the Linux kernel v3.9.0 code I mention above is presented in the paper from WiMob2015. A paper giving some preliminary results for TCP performance using the same Linux kernel will be presented in a few weeks at AINTEC2016 (the paper will be Open Access on the ACM digital library), and there are more extensive evaluation results with TCP making their way into publications (work in progress). The WiMob2015 paper and the AINTEC 2016 papers between them show that ILNPv6 network layer soft-hand works, and has good performance compared to Mobile IPv6, at least in the lab environment that we used. The evaluation has not considered 4G or 5G directly (yet).

Cheers,
--/Saleem

Tom

CB

On Mon, Nov 14, 2016 at 3:07 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Nov 14, 2016 at 11:54 PM, Ca By <[email-masked]<mailto:[email-masked]>> wrote:
This is a helpful document, but i may be wrong, but i do not believe ILNP requires any change to the LTE core network and it does not require a translation function at all.

For me, the major upside in ILNP is that it is a purely host based e2e solution. So, the impacts of ILNP are strictly isolated to the host and DNS.

ILNP is a nice fit for 5G since 5G hosts modifications are clearly in scope for 5G and ILNP solves mobility issue, so the 5G core can be much simpler since it does not need to track mobility of a user.... this is all handled in the UE... and becomes a massive simplification since the 5G core only needs to authenticate and attach the user ...not manager user mobility state. No tunnel. No nat.

ILNP is the only solution that does not introduce a new box, and it is the only solution that meaningfully reduces state in the operator network.

ILA does not require a new box. It can run in hosts like ILNP _or_ in the network more like NAT. This achieves a more flexible solution. Also different from  ILNP is that ILA is transport layer agnostic so it will work with any transport layer protocol not just a limited set of supported transport.

By the way, I still have been unable to find any source code for ILNP. If anyone knows where I might be able to find that please let me know. Without an implementation it's really difficult to evaluate it as a potential solution.

Thanks,
Tom

I would also not characterize ILA as an upgrade to ILNP. Adding a NAT is just a different implementation, not an upgrade.

On Sun, Nov 13, 2016 at 4:09 PM Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:
A new version of I-D, draft-vonhugo-5gangip-ip-issues-01.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Abstract:

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<http://tools.ietf.org/>.

The IETF Secretariat

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Nov 2016 15:02:21 -0800

> Very good point. The ILNP opportunity i see is to eliminate the middle box.  As where ILA (and LISP) requires the middle box to be the anchor point for mobility, right?  These anchor points are frequently magnets for operational failure as well as surveillance. 

Both LISP and ILA can run in the host where there are no anchor points. But as Tom mentioned, this may be a much harder deployment challenge then making a solution network based.

You are going to have to put anchor points in the network for scale, fast handoff, and NAT-traversal. If there is a requirement for IPv4, which there should be, NATs will be in the carrier path. In addition, you will need anchor points for multicast replication unless the carrier is sincerely committed to put native multicast routing throughout the network.

Those are the reality challenges we face. You need a robust solution, and better to be a single solution to reduce complexity, that has all the features above. 

LISP is the only protocol that exists (with 10 years of development expeience and 6 years of deployment experience) that can do mobility, multi-homing, multicast, and multiple address-families at the same time.

Dino

---

From: Ca By <[email-masked]>
Date: Tue, 15 Nov 2016 23:33:10 +0000

Sorry for top posting.... gmail broke inline editing on iOS....

Why is ipv4 required? I stopped assigning ipv4 to android phones in 4.3 and
the same will happen to Apple devices in 10.2.

There is no good reason to support ipv4 (uniquely assigned to each ue) in
5G IMHO. Obviously, there needs to be NAT64 to access the legacy internet,
but that is ipv6 across the 5G RAN and core.

And, the IAB has stated ipv4 is not required going forward , please see

https://www.iab.org/documents/correspondence-reports-documents/2016-2/iab-statement-on-ipv6/

Regards,
Cameron

On Tue, Nov 15, 2016 at 3:02 PM Dino Farinacci <[email-masked]> wrote:

> Both LISP and ILA can run in the host where there are no anchor points.
> But as Tom mentioned, this may be a much harder deployment challenge then
> making a solution network based.
>
> You are going to have to put anchor points in the network for scale, fast
> handoff, and NAT-traversal. If there is a requirement for IPv4, which there
> should be, NATs will be in the carrier path. In addition, you will need
> anchor points for multicast replication unless the carrier is sincerely
> committed to put native multicast routing throughout the network.
>
> Those are the reality challenges we face. You need a robust solution, and
> better to be a single solution to reduce complexity, that has all the
> features above.
>
> LISP is the only protocol that exists (with 10 years of development
> expeience and 6 years of deployment experience) that can do mobility,
> multi-homing, multicast, and multiple address-families at the same time.
>
> Dino
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Nov 2016 15:43:29 -0800

> Why is ipv4 required?  I stopped assigning ipv4 to android phones in 4.3 and the same will happen to Apple devices in 10.2. 

I have my reasons below. There will still be services and applications that require IPv4. Do you think an IPv6-only UE is practical?

The requirements in the presentation yesterday also indicated IPv4 support.

> There is no good reason to support ipv4 (uniquely assigned to each ue) in 5G IMHO. Obviously, there needs to be NAT64 to access the legacy internet, but that is ipv6 across the 5G RAN and core. 

We can argue over the requirements but IPv4 is not the only reason to have an anchor point.

> https://www.iab.org/documents/correspondence-reports-documents/2016-2/iab-statement-on-ipv6/

And do you see the vendors rushing to remove it from the stack? That would be product suicide.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 Nov 2016 08:44:06 +0900

On Wed, Nov 16, 2016 at 7:34 AM, Saleem Bhatti <[email-masked]>
wrote:

> Hello, Tom et al.
>
> On 15 Nov 2016, at 05:13, Tom Herbert <[email-masked]> wrote:
>
>
>
> be translated to a another address for transit across the network.
>
>
> ILNP is not a type of NAT. ILNP "addresses" (actually identifier-locator
> vectors - I-LVs) do not need to be translated.
>
> ILNP can, optionally, support Locator Rewriting, but that is not required
> for the normal operation of ILNP, and even when Locator Rewriting is used,
> end-to-end state for transport protocols is persevered.
>
> So in either case, if someone is sending to a mobile host then translation
> needs to be done somewhere in the path. In ILNP this can only be done in
> the source host, in ILA this can be done either in hosts or devices in the
> forwarding node is in the network not at the source host.
>
>
> I agree that a non ILA/ILNP/LISP node communicating with a ILA/ILNP/LISP
> node would require some sort of middlebox.
>
> With an ILNPv6 host (ILNPv6 is ILNP implemented as a superset of IPv6), if
> that host detects communication being initiated from an IPv6 node, the
> ILNPv6 node would switch to IPv6.
>
> I do not believe that the scenarios for ILNPv6/IPv6 interoperation have
> been explored, but I am happy to be proved wrong.
>
> ILNP is designed to be end-2-end so this doesn't work natively; I believe
> there may have been some discussion of ILNP proxies to provide this
> Certainly, the ILNP architectural design was aimed to honour the
> end-to-end principle. However, that single email (from Nov 2008), I believe
> does not really capture the whole discussion well.
>
> I think a good summary of the relative pros and cons for ILNP and LISP are
> summarised in RFC6115 (from Feb 2011, Section 2 for LISP, Section 12 for
> ILNP). Of course, that predates ILA, and also the state of both ILNP and
> LISP will have moved on since the publication for RFC6115, but I think the
> core discussion is still fair.
>
> In terms of whether end host updates are practical, I believe they are -
> host updates roll out regularly for most modern OSs, including for mobile
> devices.
>

Hi Saleem,

I can't speak for IOS or Windows, but I can probably describe the
challenges of getting this in to Android. First, getting code into Linux is
most likely a prerequisite. If ILNP requires changes to every transport
layer I think it's going to be a very hard sell. If the code is
compartmentalized into a single module that will be better. This was a
major part of ILA designed, we didn't change any code outside of the ILA
model.

Once the code is in Linux, then you'll need to convince Android (Google) to
enable it. This is probably also a huge challenge. They have been very
conservative with new networking features, for instance we invented TCP
Fast Open at Google over five years ago and I still don't believe they have
fully enabled it for Android yet. This is complicated by the fact that
Google seems to be moving towards userspace transports like QUIC.
Presumably they could modify QUIC and Android to support ILNP, but then
that would only work on Android and so non-Android QUIC users become gated
on getting support in other OSes (WIndows, IOS) which is exactly what QUIC
is designed to avoid.

> Regarding a comment in a previous email about public (non-)availability of
> code for ILNP, that is a fair point, and something I am working on. I have
> some code for Linux kernel v3.9.0 -- implementing items a) and b) above --
> but it needs to be tidied up and moved across to a more modern Linux kernel
> version -- as well as being modified for item c) above. The aim is to get
> the code into one of the main upstream Linux kernel versions as soon as I
> can (which will be sometime in 2017).
>

Thanks for the information. One thing you may consider is posting an early
version of the patches on netdev as RFC. That might be good to get some
discussion going

Tom

>
> In terms of your comment on evaluation, I am not sure if your intention is
> to inspect the structure/engineering of the code, or to evaluate its
> operation and performance. If it is the latter, there are various papers at:
>
> Some evaluation of UDP and mobility with the Linux kernel v3.9.0 code I
> mention above is presented in the paper from WiMob2015. A paper giving some
> preliminary results for TCP performance using the same Linux kernel will be
> presented in a few weeks at AINTEC2016 (the paper will be Open Access on
> the ACM digital library), and there are more extensive evaluation results
> with TCP making their way into publications (work in progress). The
> WiMob2015 paper and the AINTEC 2016 papers between them show that ILNPv6
> network layer soft-hand works, and has good performance compared to Mobile
> IPv6, at least in the lab environment that we used. The evaluation has not
> considered 4G or 5G directly (yet).
>
> Cheers,
> --/Saleem
>
>
>
> Tom
>
> CB
>>

---

From: Ca By <[email-masked]>
Date: Tue, 15 Nov 2016 23:55:58 +0000

Dino,

Yes, ipv6-only UEs are practical. We launched them in android 3+ years ago
(464xlat).

We have ipv6-only iPhone in beta on 10.2.

In 2017, T-Mobile US shops simply won't have any phones in the shops that
have ipv4 addresses assigned from the network or emit native ipv4 packets
across the radio by default.

I do not consider that "product suicide". It is executing a forward looking
strategy.

Regards,
Cameron

On Tue, Nov 15, 2016 at 3:43 PM Dino Farinacci <[email-masked]> wrote:

> > Why is ipv4 required?  I stopped assigning ipv4 to android phones in 4.3
> and the same will happen to Apple devices in 10.2.
>
> I have my reasons below. There will still be services and applications
> that require IPv4. Do you think an IPv6-only UE is practical?
>
> > There is no good reason to support ipv4 (uniquely assigned to each ue)
> in 5G IMHO. Obviously, there needs to be NAT64 to access the legacy
> internet, but that is ipv6 across the 5G RAN and core.
>
> > You are going to have to put anchor points in the network for scale,
> fast handoff, and NAT-traversal. If there is a requirement for IPv4, which
> there should be, NATs will be in the carrier path. In addition, you will
> need anchor points for multicast replication unless the carrier is
> sincerely committed to put native multicast routing throughout the network.
> >
> > Those are the reality challenges we face. You need a robust solution,
> and better to be a single solution to reduce complexity, that has all the
> features above.
> >

---

From: Ca By <[email-masked]>
Date: Tue, 15 Nov 2016 23:59:36 +0000

Tom,

I am not scared of implementation challenges.

We got RFC6877 into Android and something similar into iOS. Why would ILNP
be any different?

Removing the mobile core and replacing it with an e2e solution is very
appealing to operators, UE software folks, and cloud software folks.

Regards,
Cameron

On Tue, Nov 15, 2016 at 3:44 PM Tom Herbert <[email-masked]> wrote:

> Once the code is in Linux, then you'll need to convince Android (Google)
> to enable it. This is probably also a huge challenge. They have been very

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Nov 2016 16:04:52 -0800

Let’s see what the carriers would say about this. And what the 3GPP requirements are.

Dino

> On Nov 15, 2016, at 3:55 PM, Ca By <[email-masked]> wrote:
> 
> Dino,
> 
> Yes, ipv6-only UEs are practical. We launched them in android 3+ years ago (464xlat). 
> 
> In 2017, T-Mobile US shops simply won't have any phones in the shops that have ipv4 addresses assigned from the network or emit native ipv4 packets across the radio by default. 
> 
> I do not consider that "product suicide".  It is executing a forward looking strategy. 
> 
> Regards,
> Cameron
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 Nov 2016 09:20:27 +0900

On Wed, Nov 16, 2016 at 9:04 AM, Dino Farinacci <[email-masked]> wrote:

> And let's see the code also :-)

Tom

> > In 2017, T-Mobile US shops simply won't have any phones in the shops
> that have ipv4 addresses assigned from the network or emit native ipv4
> packets across the radio by default.
> >
> > > Why is ipv4 required?  I stopped assigning ipv4 to android phones in
> 4.3 and the same will happen to Apple devices in 10.2.
> >
> > > > Very good point. The ILNP opportunity i see is to eliminate the
> middle box.  As where ILA (and LISP) requires the middle box to be the
> anchor point for mobility, right?  These anchor points are frequently
> magnets for operational failure as well as surveillance.
> > >
> > > Both LISP and ILA can run in the host where there are no anchor
> points. But as Tom mentioned, this may be a much harder deployment
> challenge then making a solution network based.
> > >

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 15 Nov 2016 20:55:31 -0600

Hi Saleem,

On Tue, Nov 15, 2016 at 4:34 PM, Saleem Bhatti <[email-masked]> wrote:
> I'm not exactly sure what you mean by NAT in this context. Both ILNP and ILA
> are a type of NAT in that the destination address that host sends to is be
> translated to a another address for transit across the network.
>
>

Transport level incompatibility is a big issue, although Cameron
doesn't seem to be much concerned about it.

> needs to be done somewhere in the path. In ILNP this can only be done in the
> I do not believe that the scenarios for ILNPv6/IPv6 interoperation have been
> explored, but I am happy to be proved wrong.
>
> Certainly, the ILNP architectural design was aimed to honour the end-to-end
> principle. However, that single email (from Nov 2008), I believe does not
> really capture the whole discussion well.
>

Another concern on ILNP (maybe ILNPv6, I believe you use this term to
mean IPv6 version of ILNP) is the use of extension headers in IPv6 and
options in IPv4.
This point has been mentioned in the side meeting we had on Tuesday.

Dirk and I think that we have good interest in the group to go for  a
BoF to work on these deficiencies of ILNP to make kind of 5G ILNP.

Regards,

Behcet
> presented in a few weeks at AINTEC2016 (the paper will be Open Access on the
> ACM digital library), and there are more extensive evaluation results with
> TCP making their way into publications (work in progress). The WiMob2015
> paper and the AINTEC 2016 papers between them show that ILNPv6 network layer
> soft-hand works, and has good performance compared to Mobile IPv6, at least
> in the lab environment that we used. The evaluation has not considered 4G or
> 5G directly (yet).
>
> Cheers,
> --/Saleem
>
>
>
> Tom
>
>> CB
>>

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 16 Nov 2016 15:49:13 +0000

Tom;

On 15 Nov 2016, at 23:44, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Nov 16, 2016 at 7:34 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Hello, Tom et al.

Hi Ca,

Hi Saleem,

I can't speak for IOS or Windows, but I can probably describe the challenges of getting this in to Android. First, getting code into Linux is most likely a prerequisite. If ILNP requires changes to every transport layer I think it's going to be a very hard sell. If the code is compartmentalized into a single module that will be better. This was a major part of ILA designed, we didn't change any code outside of the ILA model.

Once the code is in Linux, then you'll need to convince Android (Google) to enable it. This is probably also a huge challenge. They have been very conservative with new networking features, for instance we invented TCP Fast Open at Google over five years ago and I still don't believe they have fully enabled it for Android yet. This is complicated by the fact that Google seems to be moving towards userspace transports like QUIC. Presumably they could modify QUIC and Android to support ILNP, but then that would only work on Android and so non-Android QUIC users become gated on getting support in other OSes (WIndows, IOS) which is exactly what QUIC is designed to avoid.

Thanks for the warning and advice.

I can imagine that, for whatever reasons, adoption of various new technologies could be difficult.

Certainly, getting the code into an upstream Linux kernel is a key step, I agree.

I have to say that I am a little perplexed that getting changes into transport code should be a "hard sell" given the number of congestion control algorithms now the Linux kernel, and with BBR on its way. (Perhaps, I am missing something here.)

Thanks for the information. One thing you may consider is posting an early version of the patches on netdev as RFC. That might be good to get some discussion going

Thanks, once more, for the advice.

Cheers,
--/Saleem

Tom

  http://ilnp.cs.st-andrews.ac.uk<http://ilnp.cs.st-andrews.ac.uk/>

Cheers,
--/Saleem

Tom

CB

Thanks,
Tom

Abstract:

The IETF Secretariat

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 16 Nov 2016 16:34:32 +0000

Hello, Behcet;

> On 16 Nov 2016, at 02:55, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi Saleem,
> 

I replied to Tom's response about this, earlier, also - I am slightly perplexed by the issue of code changes at the transport level being an issue. I agree that it would be better to have fewer changes in the stack, but where changes are needed to implement some functionality, then I would say it is worth making those changes. (Of course, it can be can argued as to whether or not some functionality is required in the first place.)

Also, from a research perspective, it would sadden me to think that certain parts of the stack should be considered off limits, and so stagnate or ossify in this way, as well as constrain the solution space(s) that might be offered in response to the challenges that are being discussed.

> This point has been mentioned in the side meeting we had on Tuesday.

Yes, ILNPv6 is ILNP implemented on IPv6, and ILNPv4 would be ILNP implemented on top of IPv4.

ILNPv4 RFC documents exist, but, as far as I know, have not received much attention in terms of implementation. My focus has been on ILNPv6, and I currently have no plans to build ILNPv4. I saw Dino's message that some might consider direct support for IPv4 to still be important going forward (which I can sympathise with).

In terms of headers and extensions to IPv6 packets required for ILNPv6:

a) Nonce Header (RFC6744)
This is a destination header extension (not hop-by-hop), so would be processed only by the end systems. This has an IANA IPv6 Destination Option Type value of 0x8B.

b) Locator Update (LU) messages (RFC6743)
This is an ICMPv6 message for which IANA has assigned the type / value 156. (This has similarities to a Binding Update message in IPv6.) Again, these would only need to be processed by the end systems.

I am guessing that, at least to a first order, the key issue would be firewall rules that might not be happy with either of these and so would drop packets. (I can imagine there are other issues also.) It would be interesting to test (or work out) what the real extent of this issue might be.

In terms of ILNPv4 header options (RFC6746), I agree that option header processing for IPv4 is highly undesirable, and, indeed, IPv4 packets with IPv4 header options are very likely to be dropped by firewalls. Especially so as neither ILNPv4 option headers or ILNPv4 LU messages (RFC6745) have IANA type values assigned to them. So, again, relating to Dino's comment in a previous message, if direct support for IPv4 is important then ILNPv4 presents an additional challenge here.

> BoF to work on these deficiencies of ILNP to make kind of 5G ILNP.

Alas, I am "resource-constrained" on travel ...

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Thu, 17 Nov 2016 04:38:41 +0900

On Thu, Nov 17, 2016 at 12:49 AM, Saleem Bhatti <[email-masked]>
wrote:

> Tom;
>
> On 15 Nov 2016, at 23:44, Tom Herbert <[email-masked]> wrote:
>
>
>
>> So in either case, if someone is sending to a mobile host then
>> translation needs to be done somewhere in the path. In ILNP this can only
>> be done in the source host, in ILA this can be done either in hosts or
>> devices in the network. The latter case would be difficult to eliminate.
>> Consider a random host on the Internet (does not support ILA or ILNP) sends
>> a  packet to a mobile host. Somewhere in the path the packet needs to be
>> transformed so it gets to the proper physical location (true for ILA, ILNP,
>> LISP, etc.). This forwarding node is in the network not at the source host.
>>
>>
>> With an ILNPv6 host (ILNPv6 is ILNP implemented as a superset of IPv6),
>> if that host detects communication being initiated from an IPv6 node, the
>> I think a good summary of the relative pros and cons for ILNP and LISP
>> are summarised in RFC6115 (from Feb 2011, Section 2 for LISP, Section 12
>> for ILNP). Of course, that predates ILA, and also the state of both ILNP
>> and LISP will have moved on since the publication for RFC6115, but I think
>> the core discussion is still fair.
>>
> I have to say that I am a little perplexed that getting changes into
> transport code should be a "hard sell" given the number of congestion
> control algorithms now the Linux kernel, and with BBR on its way. (Perhaps,
> I am missing something here.)
>

Yes, but BBR is in a well contained module. The infrastructure for having
different CCs and keeping them isolated to not be invasive with the rest of
the stack.

Tom

>
>
>> Regarding a comment in a previous email about public (non-)availability
>> of code for ILNP, that is a fair point, and something I am working on. I
>> have some code for Linux kernel v3.9.0 -- implementing items a) and b)
>> above -- but it needs to be tidied up and moved across to a more modern
>> Linux kernel version -- as well as being modified for item c) above. The
>> aim is to get the code into one of the main upstream Linux kernel versions
>> as soon as I can (which will be sometime in 2017).
>>
>
>> In terms of your comment on evaluation, I am not sure if your intention
>> is to inspect the structure/engineering of the code, or to evaluate its
>>>> I would also not characterize ILA as an upgrade to ILNP. Adding a NAT
>>>> is just a different implementation, not an upgrade.
>>>>
>>>>

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 16 Nov 2016 20:01:15 +0000

Tom;

On 16 Nov 2016, at 19:38, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Nov 17, 2016 at 12:49 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Tom;

Hi Ca,

Hi Saleem,

Yes, but BBR is in a well contained module. The infrastructure for having different CCs and keeping them isolated to not be invasive with the rest of the stack.

Aha ... so the issue is really a nervousness that the potential change is in a part of the code base that is not in a well-contained module. In that case, would it be fair to say that it is more of an engineering concern about potential side-effetcs of a code change, rather than an architectural concern about the approach being proposed?

Cheers,
--/Saleem

Tom

Cheers,
--/Saleem

Tom

Cheers,
--/Saleem

Tom

CB

Thanks,
Tom

Abstract:

The IETF Secretariat

---

From: Tom Herbert <[email-masked]>
Date: Thu, 17 Nov 2016 05:06:40 +0900

On Thu, Nov 17, 2016 at 1:34 AM, Saleem Bhatti <[email-masked]>
wrote:

> I replied to Tom's response about this, earlier, also - I am slightly
> perplexed by the issue of code changes at the transport level being an
> issue. I agree that it would be better to have fewer changes in the stack,
> but where changes are needed to implement some functionality, then I would
> say it is worth making those changes. (Of course, it can be can argued as
> to whether or not some functionality is required in the first place.)
>
> Also, from a research perspective, it would sadden me to think that
> certain parts of the stack should be considered off limits, and so stagnate
> or ossify in this way, as well as constrain the solution space(s) that
> might be offered in response to the challenges that are being discussed.
>
> Nothing is off limits. Anyone is free to add, modify, and release code
based on Linux as desired under GPL requirements. The distinction we're
making here is what is acceptable for mainline kernel. Bear in mind that
Linux is not a research OS, this code probably runs on more devices than
any other software on the planet-- so the bar is high. New functionality
needs to be weighed against the impact in terms of maintainability and
robustness of existing implementation. For this reason, acceptance into the
mainline kernel is correlated to how invasive it is to the rest of the
kernel. A good example of a feature being too invasive to be accepted is
MPTCP. This has a whole bunch of impact on the TCP code. Every time that
someone post patches for that the answer has always been the same: too much
code change in TCP. They whittled the code down a lot, but last I checked
it was still a couple thousand lines of change which is not palatable.

Again I don't want to discourage you from posting patches, I'm just trying
to give a you a heads up on the potential challenges.

Tom

> translation
> if
> been
> end-to-end
> are
> >> c) updates to getaddrinfo(3)/libc to allow access to the RFC6742 DNS
> RRs for
> >> ILNPv6
> >> (RFC6742 for the new ILNP DNS RRs is currently implemented by BIND,
> KnotDNS,
> >> and Unbind, I believe)
> >>
> >
> ILNPv4 RFC documents exist, but, as far as I know, have not received much
> attention in terms of implementation. My focus has been on ILNPv6, and I
> currently have no plans to build ILNPv4. I saw Dino's message that some
> might consider direct support for IPv4 to still be important going forward
> (which I can sympathise with).
>
> This is a destination header extension (not hop-by-hop), so would be
> processed only by the end systems. This has an IANA IPv6 Destination Option
> Type value of 0x8B.
>
> This is an ICMPv6 message for which IANA has assigned the type / value
> 156. (This has similarities to a Binding Update message in IPv6.) Again,
> these would only need to be processed by the end systems.
>
> I am guessing that, at least to a first order, the key issue would be
> firewall rules that might not be happy with either of these and so would
> drop packets. (I can imagine there are other issues also.) It would be
> interesting to test (or work out) what the real extent of this issue might
> be.
>
> In terms of ILNPv4 header options (RFC6746), I agree that option header
> processing for IPv4 is highly undesirable, and, indeed, IPv4 packets with
> IPv4 header options are very likely to be dropped by firewalls. Especially
> so as neither ILNPv4 option headers or ILNPv4 LU messages (RFC6745) have
> IANA type values assigned to them. So, again, relating to Dino's comment in
> a previous message, if direct support for IPv4 is important then ILNPv4
> presents an additional challenge here.
>
> of
> is
> the

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 17 Nov 2016 01:36:38 -0600

Hi Saleem,

> Also, from a research perspective, it would sadden me to think that certain parts of the stack should be considered off limits, and so stagnate or ossify in this way, as well as constrain the solut…

Please don't get me wrong.
We value ILNP and your contributions very highly.
Stagnating, ossifying, no way.
Please keep an eye on our work, please continue to contribute on the
list and if you can in the face to face meetings as well.

> Alas, I am "resource-constrained" on travel ...

Sure, we are all resource-constrained.

Regarding the software issues, I see it as possible future Hackathon
activity from our group.

Regards,

Behcet

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 17 Nov 2016 10:08:59 +0000

On 16 Nov 2016, at 20:06, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Nov 17, 2016 at 1:34 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Hello, Behcet;

> On 16 Nov 2016, at 02:55, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Saleem,
>
> On Tue, Nov 15, 2016 at 4:34 PM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
>> Hello, Tom et al.
>>

Nothing is off limits. Anyone is free to add, modify, and release code based on Linux as desired under GPL requirements. The distinction we're making here is what is acceptable for mainline kernel. Bear in mind that Linux is not a research OS, this code probably runs on more devices than any other software on the planet-- so the bar is high. New functionality needs to be weighed against the impact in terms of maintainability and robustness of existing implementation. For this reason, acceptance into the mainline kernel is correlated to how invasive it is to the rest of the kernel. A good example of a feature being too invasive to be accepted is MPTCP. This has a whole bunch of impact on the TCP code. Every time that someone post patches for that the answer has always been the same: too much code change in TCP. They whittled the code down a lot, but last I checked it was still a couple thousand lines of change which is not palatable.

Again I don't want to discourage you from posting patches, I'm just trying to give a you a heads up on the potential challenges.

Very useful information, Tom, especially the anecdotes - thank you.

Cheers,
--/Saleem

Tom

Cheers,
--/Saleem