Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017

From: Toerless Eckert <[email-masked]>
Date: Thu, 14 Sep 2017 23:18:45 +0200

Hi Brian, 

Sorry, for the delay. I have not sen further feedback on stable-connectivity-05
bside this mail of yours. See answers below, let me know if you want me to rev
with the one possible textual improvement or if we think -05 is good enough.

Cheers
    Toerless

On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote:
> I'm just coming back on a couple of points. Generally -05 is almost there...
>
> > See the rewritten SIIT section. IMHO, there can be no simpler "network" based
> > address translation. Where network based means that the translation happens
> > in some device he network operator needs to provision. Like the ACP edge device.
> > Or even an additional address translation device.
> > 
> > So, the only IMHO easier option is when the OS of the NMS host would internally
> > have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6.
> 
> Yes, that is exactly the effect of 464XLAT in the end-system (not in the
> router).

I found rfc6877 a confusing read, but from what i figure, it's not exactly what
i was thinking of: with rfc6877, you still need the server side to have a reachable/mappable
IPv4 address, and that is something any device in the ACP does not have naturally.
(aka: NOC server as client connecting to ACP device, ACP device is server).

If i already need to set up some other form of NAT to give an ACP device an outside IPv4
address, then 464XLAT does not buy me any simplifications.

I was rather thinking of taking the NAT network function that i was describing
and simply embody them in a set of linux NAT rules configured on on the NOC linux
system that runs the IPv4-only NMS application. Aka: Not a novel NAT scheme,
but just a way to avoid having to deal with the problem in the network (adding a NAT
device you would otherwise not need):

Its a NMS host problme, deal with it in the NMS host. If you can not change the app,
let the OS do the NAT. Of course, this would not work for the poor customer who bought
a black-blox NMS soution which may run windows, or where you can not configure the
linux. Then again, nowadays, most NOC components should be software in VMs, and
for those, you should certainly be able to do the NAT in the vswitch of the server.

In any case: my interest in expanding the NAT section further is quite limited.
The whole goal of the NAT section was to explain that you need 1:1 address mapping
and that you can hack this up in likely most available routers with NAT support,
but do not consider this to be a good long term solution but use it as a stopgap
to upgrade your NOC software to IPv6.

No idea why IETF draft/RFC doesn't allow me to write such a simple paragraph ;-))

So, let me know if you feel strongly anything that should be added/modified to the
NAT section.

> > Alas, i didn't have the time to investigate these options. And most likely if at
> > all you could only make those work for linux.
> 
> Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they
> will all support IPv6 anyway?

Lets hope so, yes.

> > So, for now i just remove the note and clarified the last sentence a bit.
> > 
> > If there is anything specific to be said bout why 464XLAT might be better
> > longer term, let me know and i can add it. For now it looks like yet another
> > network device configured option to me, but i have not tried to understand it
> > all the way.
> 
> I think you'd need one of the 464XLAT authors to have a look at the scenario,
> because I don't claim to understand it all.

Well, the analysis i made above (server must support IPv4 as stated in the RFC)
makes me discount it as a more beneficial option to mention.

> >>>    Using current registration options implies that there will not be
> >>>    reverse DNS mapping for ACP addresses.
> >>
> >> Really? I assume we're talking about two-faced DNS, and afaik nothing
> >> stops an operator providing reverse mapping in the private DNS.
> >> That seems to be implied by the following paragraphs, so the text
> >> seems inconsistent anyway.
> > 
> > I know it under the name "split-horizon DNS". Is there any reference ?
> 
> The DNS community in the IETF hates split DNS so much that
> not much has been written about it. I did find these:
> https://tools.ietf.org/html/rfc6950#section-4
> https://tools.ietf.org/html/rfc7157#section-6.3
> https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens

RFC1918 actually explains it succinctly without giving it a name.
RFC4193 only tells you what you shouldn't do with DNS. How helpfull ;-)

So, let me know if you think it's worth creating another stable-connectivity rev,
i'd suggest to replace the "split-horizon" sentence with:

Operators may therefore need to use a private DNS setup for the ACP ULA
addresses. This is the same setup that would be necessary for using
RFC1918 addresses in DNS. See for example [RFC1918] section 5, last
paragraph. In [RFC6950] section 4, these setups are discussed in more detail.

Cheers
    Toerless

> Regards,
>     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Sep 2017 11:05:51 +1200

To cut a long story short, here's a friendly suggestion. The goal is to avoid
comments during IETF/IESG review that the NAT text is too vague:

OLD
   To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6
   NAT can be used.  This NAT setup could for example be done in Rt1r1
   in above picture to also support IPv4 only NMS hots connected to
   NOClan.

NEW
   To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6
   translation [RFC 6145] could be used. This could for example be done in Rt1r1
   in the above picture to also support IPv4-only NMS hosts connected to
   NOClan. Details of the address mapping to be used would depend on
   the exact scenario and are not specified here.

> paragraph. In [RFC6950] section 4, these setups are discussed in more detail.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Sep 2017 12:56:39 -0400

> the exact scenario and are not specified here.

+1
RFC7915 obsoletes 6145, and there is also both:

RFC7756:Stateless IP/ICMP Translation for IPv6 Internet Data Center
             Environments (SIIT-DC): Dual Translation Mode

but specifically: rfc7755
SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments

builds upon 7915.  which I suggest be mentioned.  They solve exactly the
problem.   (I'm a big fan...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Sep 2017 08:34:50 +1200

On 16/09/2017 04:56, Michael Richardson wrote:
> RFC7915 obsoletes 6145, 

Oops, sorry about that.

> and there is also both:

I'm not, but unfortunately I agree that sometimes such things are unavoidable.
However, it's a messy topic and limiting the discussion in the present draft
seems best to me.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 18 Sep 2017 07:38:48 +0200

Thanks, Brian:

The "OLD" paragraph you list was from -04. After your review i had already
changed this in -05 to

NEW:

   To connect IPv4 only management plane devices/applications with the
   ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is
   necessary.  The basic mechanisms for this are defined in SIIT
   ([RFC7915]).  There are multiple solutions using this mechanisms.  To
   understand the possible solutions, we consider the requirements:
....

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt

I also did spend a good amount of time because of your -04 review and prior
request by mohammed to detail in the following parapgraphs the possible
options in more detail.  That text leverages the 'SIIT' term and
discusses the EAM solutions (RFC7757 is best).

Given how this is an informational OPS document,
i think it is helpfull to elaborate on the understood details of
requirements and how known current solutions fit them.

 The fact that none of the
currently defined NAT solutions provides for the most simple possible
configuration (aka: minimum number of prefix EAM's to configure) is
also IMHO a perfectly valid outcome for an OPS document.

It could mean that users will simply accept the need for longer mnaual
NAT config (long list of 1:1 mappings) or vendors implement a proprietary
EAM (explicit address mapping) CLI to make it simpler. Or users will
move faster to IPv6 on the NOC ;-)

So, for the time being, i just commited -06 with the second fix.

Let me know what you folks think about WG last call status of
the stable connectivity draft.

Cheers
    Toerless

On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 18 Sep 2017 07:45:29 +0200

> RFC7915 obsoletes 6145, and there is also both:

That's the one i had used already in static-connectivity-05 as the primary reference.

> problem.   (I'm a big fan...)

When i was comparing the different solutions, i found RFC7757 to be
best suited in the case of ACP because of its flexibility. Thats
what i am referring to in stable-connectivity-05. I didn't find
that RFC7755 was adding any more benefits for the ACP NAT use case.

Check out the section about NAT in stable-connectivity-05 (or -06, unchanged).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Sep 2017 08:11:56 +1200

This is embarassing. For some reason I completely missed the announcement
of draft-ietf-anima-stable-connectivity-05, until today.

I have now looked at the -05 and -06 versions and I'm happy with the result.

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 19 Sep 2017 20:53:23 +0200

Thanks, Brian!

Sheng: i think/hop i am trough all outstanding issues with stable-connectivity. Please
decide what to do next to move to next stage, eg: another WG last call or pass to
IETF/IESG.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 20 Sep 2017 00:54:07 +0000

Hi, Toerless,

Thanks for your hard and fruitful work. Giving the change mount from -03 version, which is the base for the first WGLC, I feel another WGLC is needed. I will launch a short one-week WGLC on this. Meanwhile, I still not receive IPR disclosure from all authors. I would not be able to move this document forward with the proper IPR disclosures, even after the WGLC passed.

Cheers,

Sheng

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Toerless Eckert
> Sent: Wednesday, September 20, 2017 2:53 AM
> To: Brian E Carpenter
> Cc: Anima WG
> Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 -
> Respond by July 28, 2017
> 
> Thanks, Brian!
> 
> Sheng: i think/hop i am trough all outstanding issues with
> stable-connectivity. Please decide what to do next to move to next stage,
> eg: another WG last call or pass to IETF/IESG.
> 
> Cheers
>     Toerless
> 
> > This is embarassing. For some reason I completely missed the
> > announcement of draft-ietf-anima-stable-connectivity-05, until today.
> >
> > > The "OLD" paragraph you list was from -04. After your review i had
> > > already changed this in -05 to
> > >
> > > NEW:
> > >
> > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.
> > > ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https:/
> > > /tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt
> > >
> > > I also did spend a good amount of time because of your -04 review
> > > and prior request by mohammed to detail in the following
> parapgraphs
> > > the possible options in more detail.  That text leverages the 'SIIT'
> > > term and discusses the EAM solutions (RFC7757 is best).
> > >
> > > Given how this is an informational OPS document, i think it is
> > > helpfull to elaborate on the understood details of requirements and
> > > how known current solutions fit them.
> > >
> > > currently defined NAT solutions provides for the most simple
> > > possible configuration (aka: minimum number of prefix EAM's to
> > > configure) is also IMHO a perfectly valid outcome for an OPS
> document.
> > >
> > > It could mean that users will simply accept the need for longer
> > > mnaual NAT config (long list of 1:1 mappings) or vendors implement a
> > > proprietary EAM (explicit address mapping) CLI to make it simpler.
> > > Or users will move faster to IPv6 on the NOC ;-)
> > >
> > > Let me know what you folks think about WG last call status of the
> > > stable connectivity draft.
> > >
> > > Cheers
> > >     Toerless
> > >
> > >> To cut a long story short, here's a friendly suggestion. The goal
> > >> is to avoid comments during IETF/IESG review that the NAT text is too
> vague:
> > >>
> > >> OLD
> > >>> Operators may therefore need to use a private DNS setup for the
> > >>> ACP ULA addresses. This is the same setup that would be necessary
> > >>> for using
> > >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5,
> > >>> last paragraph. In [RFC6950] section 4, these setups are discussed in
> more detail.
> > >>
> > >> Regards
> > >>    Brian
> > >>
> > >>> Sorry, for the delay. I have not sen further feedback on
> > >>> stable-connectivity-05 bside this mail of yours. See answers
> > >>> below, let me know if you want me to rev with the one possible
> textual improvement or if we think -05 is good enough.
> > >>>
> > >>> Cheers
> > >>>     Toerless
> > >>>
> > >>>>> See the rewritten SIIT section. IMHO, there can be no simpler
> > >>>>> "network" based address translation. Where network based
> means
> > >>>>> that the translation happens in some device he network operator
> needs to provision. Like the ACP edge device.
> > >>>>> So, the only IMHO easier option is when the OS of the NMS host
> > >>>>> would internally have IPv4/IPv6 translation so the device/VM
> looks to the outside like full IPv6.
> > >>>>
> > >>>> Yes, that is exactly the effect of 464XLAT in the end-system (not
> > >>>> in the router).
> > >>>
> > >>> I found rfc6877 a confusing read, but from what i figure, it's not
> > >>> exactly what i was thinking of: with rfc6877, you still need the
> > >>> server side to have a reachable/mappable
> > >>> If i already need to set up some other form of NAT to give an ACP
> > >>> device an outside IPv4 address, then 464XLAT does not buy me any
> simplifications.
> > >>>
> > >>> I was rather thinking of taking the NAT network function that i
> > >>> was describing and simply embody them in a set of linux NAT rules
> > >>> configured on on the NOC linux system that runs the IPv4-only NMS
> > >>> application. Aka: Not a novel NAT scheme, but just a way to avoid
> > >>> having to deal with the problem in the network (adding a NAT
> > >>> Its a NMS host problme, deal with it in the NMS host. If you can
> > >>> not change the app, let the OS do the NAT. Of course, this would
> > >>> not work for the poor customer who bought a black-blox NMS
> soution
> > >>> which may run windows, or where you can not configure the linux.
> > >>> Then again, nowadays, most NOC components should be software in
> VMs, and for those, you should certainly be able to do the NAT in the
> vswitch of the server.
> > >>>
> > >>> The whole goal of the NAT section was to explain that you need 1:1
> > >>> address mapping and that you can hack this up in likely most
> > >>> available routers with NAT support, but do not consider this to be
> > >>> a good long term solution but use it as a stopgap to upgrade your
> NOC software to IPv6.
> > >>>
> > >>> So, let me know if you feel strongly anything that should be
> > >>> added/modified to the NAT section.
> > >>>
> > >>>>> Alas, i didn't have the time to investigate these options. And
> > >>>>> most likely if at all you could only make those work for linux.
> > >>>>
> > >>>> Linux or Windows, yes. In a vendor's router o/s, who knows? But
> > >>>> maybe they will all support IPv6 anyway?
> > >>>
> > >>> Lets hope so, yes.
> > >>>
> > >>>>> If there is anything specific to be said bout why 464XLAT might
> > >>>>> be better longer term, let me know and i can add it. For now it
> > >>>>> looks like yet another network device configured option to me,
> > >>>>> but i have not tried to understand it all the way.
> > >>>>
> > >>>> I think you'd need one of the 464XLAT authors to have a look at
> > >>>> the scenario, because I don't claim to understand it all.
> > >>>
> > >>> Well, the analysis i made above (server must support IPv4 as
> > >>> stated in the RFC) makes me discount it as a more beneficial option
> to mention.
> > >>>
> > >>>>>> Really? I assume we're talking about two-faced DNS, and afaik
> > >>>>>> nothing stops an operator providing reverse mapping in the
> private DNS.
> > >>>>>> That seems to be implied by the following paragraphs, so the
> > >>>>>> text seems inconsistent anyway.
> > >>>>>
> > >>>> The DNS community in the IETF hates split DNS so much that not
> > >>>> much has been written about it. I did find these:
> > >>> So, let me know if you think it's worth creating another
> > >>> stable-connectivity rev, i'd suggest to replace the "split-horizon"
> sentence with:
> > >>>
> > >>> Operators may therefore need to use a private DNS setup for the
> > >>> ACP ULA addresses. This is the same setup that would be necessary
> > >>> for using
> > >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5,
> > >>> last paragraph. In [RFC6950] section 4, these setups are discussed in
> more detail.
> > >>>
> > >>> Cheers
> > >>>     Toerless
> > >>>
> > >>>> Regards,
> > >>>>     Brian
> > >>>
> > >>

---

From: "Michael H. Behringer" <[email-masked]>
Date: Wed, 20 Sep 2017 09:17:50 +0200

Hi Sheng,

I'm not aware of any IPR relating to this document.

Michael