Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 34

From: Tariq Saraj <[email-masked]>
Date: Tue, 9 Dec 2014 15:35:12 +0500

I don't understand the reason for discussion on SIIT when IVI is there. The
flaws are addressed and mitigated in IVI.

On Mon, Dec 8, 2014 at 10:47 PM, <[email-masked]> wrote:

> Send v6ops mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/v6ops
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of v6ops digest..."
>
> Today's Topics:
>
>    1. Re: draft-anderson-v6ops-siit-eam-01 (Tore Anderson)
>    2. Re: draft-anderson-v6ops-siit-dc-01 (Tore Anderson)
>    3. Re: Working Group Administrivia (Ole Troan)
>    4. Re: draft-anderson-v6ops-siit-dc-01 (Ca By)
>    5. Re: PMTUD forever, was: MTUs on the general Internet
>       (Templin, Fred L)
>    6. Document Action: 'Analysis of Failure Cases in IPv6 Roaming
>       Scenarios' to Informational RFC
>       (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt) (The IESG)
>
>
> ---------- Forwarded message ----------
> From: Tore Anderson <[email-masked]>
> To: Ca By <[email-masked]>
> Cc: IPv6 Ops WG <[email-masked]>
> Date: Mon, 8 Dec 2014 09:27:46 +0100
> Subject: Re: [v6ops] draft-anderson-v6ops-siit-eam-01
> Hi Cameron,
>
> > I have read draft-anderson-v6ops-siit-eam-01
> >
> > I support the working group adopting this document, this is helpful and
> > meaningful work.
> >
> > I have a few comments that are mostly editorial in nature, i believe the
> > document is technically sound as written today.
>
> Thank you!
>
> > Purely editorial, i suggest locally adding the definitions
> > for IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses.
> If
> > you are taking up space to define them, then go ahead and do the reader
> the
> > favor of defining them.
> >
> > In section 3.2 there is this sentence:  "If a matching
> >       EAM entry is found, the address MUST be translated to IPv6 by
> >       substituting its IPv4 Prefix value for the corresponding IPv6
> >       Prefix from the EAM entry."
> >
> > I don't like the word "substituting" since a reader my believe that one
> > simply does  a substitution of the IPv4 address for the IPv6.  It would
> be
> > more precises to continuing using the term translate which explicitly
> > references the packet treatment procedure in SIIT.  Perhaps rephrase to
> > "... MUST be translated to IPv6 in accordance with the EAMT..."
>
> This text has undergone a lot of back and forth between myself and
> another reviewer (Alberto Leiva). The problem he identified with saying
> something like what you propose, is that it fails to say *exactly* what
> should happen. Say you have $addr="192.0.2.123", $eam4="192.0.2.0/24",
> $eam6="2001:db8::/112". Now what? You have those three pieces of
> information, but nothing saying how those should be combined or
> manipulated to form a new IPv6 address.
>
> You could certainly say that it goes without saying and needs no further
> explanation, but Alberto thought it was best if it was explicit and as
> clear as possible. That's why we landed on "substitute", the reasoning
> is that if you start out with $addr="192.0.2.123", then you first take
> away the prefix bits found in $eam4, temporarily leaving you with
> $addr=".123" (i.e., "0x7b"), and then putting in the $eam6 prefix bits
> instead, leaving you with $addr="2001:db8::7b", and you're done. So
> what you do, essentially, is to substitute the EAM4 prefix for the EAM6
> prefix. (If you're familiar with Perl, the pseudocode would go something
> like "$addr =~ s/^$eam4/$eam6/".)
>
> That said, I'm not terribly happy with the current text either. If you
> or anyone else have any suggestions on how to make it better and
> clearer, while still remaining explicit about the procedure/algorithm,
> that would be much appreciated.
>
> Tore
>
>
>
>
> ---------- Forwarded message ----------
> From: Tore Anderson <[email-masked]>
> To: Ca By <[email-masked]>
> Cc: IPv6 Ops WG <[email-masked]>
> Date: Mon, 8 Dec 2014 09:42:53 +0100
> Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-01
> * Ca By <[email-masked]>
>
> > I have read  draft-anderson-v6ops-siit-dc-01.
> >
> > I support the document to be republished as a WG informational document
> > with  the RFC6145 changes  moved into a new document.
>
> Thank you!
>
> > I have a one minor comments about draft-anderson-v6ops-siit-dc-01.
> >
> > The I-D identifies a real network scaling problem where dual-stack is not
> > an acceptable solution since it does not allow network operators to
> > decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot
> > scale beyond IPv4 address holdings with dual-stack.  The IETF needs to
> > provide better guidance than  "dual-stack everything".  But, the I-D does
> > not address the simplest solution of simply having IPv4 nodes for IPv4
> > traffic and IPv6 nodes for IPv6 traffic.  This allows a data center
> > operator to get the most usage out of scarce IPv4 nodes since they pick
> up
> > the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6
> > nodes pickup the IPv6 capable users.  Now, this approach of IPv4-only
> nodes
> > and IPv6-only nodes works great when you are Facebook and your smallest
> > unit of provisioning is a fully packed rack of gear.  If you are a
> smaller
> > operator, you may not have enough traffic to justify an IPv6-only node,
> yet
> > you still have to scale nodes beyond IPv4 holdings.  There is also the
> case
> > where uniformity of provisioning is seen as being a higher value than
> > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01
> > certainly fits a need, but it should be context of dual-stack and single
> > stack v4 and v6.
>
> I'm not so sure about having separate IPv4-only and IPv6-only
> infrastructures solves anything, actually...
>
> To continue the Facebook analogy with a rack of IPv4-only frontend
> nodes and another rack of IPv6-only frontend nodes that serve IPv4-only
> and IPv6-capable users: Presumably all those users need to be shown the
> same content, regardless of which IP version they used to request it.
> So those IPv4/IPv6-only frontend racks necessarily share a common set
> of backend servers - and if they're to be reachable from both the
> IPv4-only and the IPv6-only frontend nodes, then the backend nodes must
> necessarily be dual-stack.
>
> So we're back to IPv4 being a limiting factor for scaling, and in my
> experience the number of backend nodes usually greatly outnumber the
> number of frontend nodes so really this is where you primarily would
> want to avoid dual-stack. (If we're talking about Facebook or someone
> of similar size, dual-stack using RFC1918 for IPv4 in the backend
> doesn't necessarily scale well enough either.)
>
> Tore
>
>
>
>
> ---------- Forwarded message ----------
> From: Ole Troan <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>
> Date: Mon, 8 Dec 2014 11:06:24 +0100
> Subject: Re: [v6ops] Working Group Administrivia
> >>
> >> 2014-10-27           draft-ietf-v6ops-dhcpv6-slaac-problem
> http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
> >
> > I'm of the party that believes that there is a defect in the IPv6
> > specifications in this area that needs to be fixed. I don't care whether
> > this draft becomes an RFC, but I do care about the fix. As long as
> > there's no sign of somebody fixing the specs, I like having this
> > draft around.
>
> since we haven't been able to agree on a fix over the last decade, I would
> not recommend for you to hold your breath waiting for one.
>
> I do think it is useful to have the implementation report that this
> document is around.
>
> cheers,
> Ole
>
>
>
> ---------- Forwarded message ----------
> From: Ca By <[email-masked]>
> To: Tore Anderson <[email-masked]>
> Cc: IPv6 Ops WG <[email-masked]>
> Date: Mon, 8 Dec 2014 07:33:19 -0800
> Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-01
>
>
> On Monday, December 8, 2014, Tore Anderson <[email-masked]> wrote:
>
>> * Ca By <[email-masked]>
>>
>> > I have read  draft-anderson-v6ops-siit-dc-01.
>> >
>> > I support the document to be republished as a WG informational document
>> > with  the RFC6145 changes  moved into a new document.
>>
>> Thank you!
>>
>> > I have a one minor comments about draft-anderson-v6ops-siit-dc-01.
>> >
>> > The I-D identifies a real network scaling problem where dual-stack is
>> not
>> > an acceptable solution since it does not allow network operators to
>> > decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot
>> > scale beyond IPv4 address holdings with dual-stack.  The IETF needs to
>> > provide better guidance than  "dual-stack everything".  But, the I-D
>> does
>> > not address the simplest solution of simply having IPv4 nodes for IPv4
>> > traffic and IPv6 nodes for IPv6 traffic.  This allows a data center
>> > operator to get the most usage out of scarce IPv4 nodes since they pick
>> up
>> > the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6
>> > nodes pickup the IPv6 capable users.  Now, this approach of IPv4-only
>> nodes
>> > and IPv6-only nodes works great when you are Facebook and your smallest
>> > unit of provisioning is a fully packed rack of gear.  If you are a
>> smaller
>> > operator, you may not have enough traffic to justify an IPv6-only node,
>> yet
>> > you still have to scale nodes beyond IPv4 holdings.  There is also the
>> case
>> > where uniformity of provisioning is seen as being a higher value than
>> > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01
>> > certainly fits a need, but it should be context of dual-stack and single
>> > stack v4 and v6.
>>
>> I'm not so sure about having separate IPv4-only and IPv6-only
>> infrastructures solves anything, actually...
>>
>> To continue the Facebook analogy with a rack of IPv4-only frontend
>> nodes and another rack of IPv6-only frontend nodes that serve IPv4-only
>> and IPv6-capable users: Presumably all those users need to be shown the
>> same content, regardless of which IP version they used to request it.
>> So those IPv4/IPv6-only frontend racks necessarily share a common set
>> of backend servers - and if they're to be reachable from both the
>> IPv4-only and the IPv6-only frontend nodes, then the backend nodes must
>> necessarily be dual-stack.
>>
>>
> Let's assume the backend is ipv6-only.
>
> The ipv4-only front-end is in-fact dual stack but it has public v4 in
> public dns to be reached by clients but no public dns entry on the ipv6
> side.  This is what allows for the separation of ipv4 and v6 users
>
>
> So we're back to IPv4 being a limiting factor for scaling, and in my
>> experience the number of backend nodes usually greatly outnumber the
>> number of frontend nodes so really this is where you primarily would
>> want to avoid dual-stack. (If we're talking about Facebook or someone
>> of similar size, dual-stack using RFC1918 for IPv4 in the backend
>> doesn't necessarily scale well enough either.)
>>
>> Tore
>>
>
>
> ---------- Forwarded message ----------
> From: "Templin, Fred L" <[email-masked]>
> To: Jeroen Massar <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Date: Mon, 8 Dec 2014 16:23:53 +0000
> Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> More on what I said the other day, there are two magic numbers that tunnels
> need to concern themselves with: 1280 and 1500. Accommodating all packets
> within that size range while placing no explicit upper bound for
> accommodating
> larger packets is what is being proposed. In other words, no MTU clamping.
>
> Thanks - Fred
> [email-masked]
>
>
> > -----Original Message-----
> > From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
> > Sent: Saturday, December 06, 2014 8:18 AM
> > To: Jeroen Massar; [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> >
> > Hi Jeroen,
> >
> > > -----Original Message-----
> > > From: v6ops [mailto:[email-masked]] On Behalf Of Jeroen Massar
> > > Sent: Saturday, December 06, 2014 4:26 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> > >
> > > On 2014-12-06 12:20, [email-masked] wrote:
> > > >>> that should be turned off as soon as possible. That will happen as
> more
> > > >>> and more links set MTUs larger than 1500.
> > > >>
> > > >> IPv6 should also have been deployed globally as soon as possible...
> > > >
> > > > Speaking only for myself: We run with a suitable jumbo MTU on most
> > > > links *within our AS*. I see no sign of such an increased MTU
> becoming
> > > > more available on peering and transit links.
> > >
> > > Agreed.
> > >
> > > IMHO one big reason of which is that there are cases where PMTU does
> not
> > > work 100% and thus there is no real benefit of enabling larger MTUs as
> > > it will only give problems (as it is something not well known) and thus
> > > higher support cost, than creating faster transfers.
> > >
> > > Hence, a status quo.
> >
> > Yes, the status has been quo for a long time, but we now have an
> opportunity
> > to move beyond that. If tunnels stop clamping the MTU and end hosts start
> > using RFC4821 larger MTUs will be possible. The good news is that fixing
> the
> > tunnels and fixing the end hosts can be done independently of one
> another.
> >
> > Thanks - Fred
> > [email-masked]
> >
> > > Greets,
> > >  Jeroen
> > >
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> ---------- Forwarded message ----------
> From: The IESG <[email-masked]>
> To: IETF-Announce <[email-masked]>
> Cc: v6ops mailing list <[email-masked]>, v6ops chair <
> [email-masked]>, RFC Editor <[email-masked]>
> Date: Mon, 08 Dec 2014 09:46:59 -0800
> Subject: [v6ops] Document Action: 'Analysis of Failure Cases in IPv6
> Roaming Scenarios' to Informational RFC
> (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt)
> The IESG has approved the following document:
> - 'Analysis of Failure Cases in IPv6 Roaming Scenarios'
>   (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt) as Informational RFC
>
> This document is the product of the IPv6 Operations Working Group.
>
> The IESG contact persons are Joel Jaeggli and Benoit Claise.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/
>
>
>
>
>
> Technical Summary
>
>    This document identifies a set of failure cases that may be
>    encountered by IPv6-enabled mobile customers in roaming scenarios.
>    The analysis reveals that the failure causes include improper
>    configurations, incomplete functionality support in equipment, and
>    inconsistent IPv6 deployment strategies between the home and the
>    visited networks.
>
> Working Group Summary
>
> China Mobile has been pretty openly discussing what they call "IPv6
> Bearer Network Trials" starting at IETF 81. As one might imagine, they
> had various problems with routing (OSPF issues due to variable MTU,
> for example) and other operational aspects. They started discussing
> their issues in roaming at IETF 87, and other operators experimenting
> with the technology chimed in. This was accepted as a working group
> draft and discussed at IETF 89, and is now being filed. There has been
> active discussion on technical points, but little real dispute.
>
> Document Quality
>
> This is operational experience, and the author list reflects the set
> of companies reporting experience with it - Deutsche Telekom AG,
> Rogers, China Mobile, and Orange. Given the range of comments made,
> the document appears to cover the bases.
>
> Note that while the document specifically addresses 3GPP networks, it
> also comments on 2G and 4G, and by extension LTE.
>
> Personnel
>
> Document Shepherd: Fred Baker Area Director: Joel Jaeggli
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 
Regards
Tariq Saraj
Center for Research in Networks and Telecom (*CoReNeT*)

---

From: Tore Anderson <[email-masked]>
Date: Tue, 9 Dec 2014 12:23:45 +0100

Hi Tariq,

(I changed the subject so that I can easily find this message later.)

* Tariq Saraj <[email-masked]>

> I don't understand the reason for discussion on SIIT when IVI is
> there. The flaws are addressed and mitigated in IVI.

See the Problem Statement section in SIIT-EAM:

http://tools.ietf.org/html/draft-anderson-v6ops-siit-eam-01#section-2

While IVI doesn't use IPv4-translatable IPv6 addresses, it uses its own
address format which share all the disadvantages of IPv4-translatable
IPv6 addresses. As specified in RFC 6219 section 3.1:

     | 0                 |32 |40                   |72             127|
     ------------------------------------------------------------------
     |                   |ff |                     |                  |
     ------------------------------------------------------------------
     |<-     PREFIX        ->|<-  IPv4 address   ->|   <- SUFFIX ->   |

The key problem with inflexible formats such as this one is that it
require that the operator must design and number his IPv6
infrastructure specifically in order to facilitate IVI translation.
This makes IVI simple at the expense of making the IPv6 infrastructure
complex.

SIIT-EAM (and by extension SIIT-DC) allows for mapping between
arbitrary IPv4 and IPv6 addresses; no particular address format is
mandated. So with SIIT-EAM you could have an IPv4 address 192.0.2.1 map
to the IPv6 address 2001:db8::f00. That is, as far as I can tell,
impossible to accomplish with IVI (in IVI, 192.0.2.1 would map to
2001:db8:ffc0:2:100:: as I understand it).

Another key point is that IVI (RFC6219) isn't a proposed standard, so
you can't implement IVI with a standard SIIT implementation. That's
true for SIIT-DC as well, and it is something I attempt to fix with
SIIT-EAM. That said, SIIT-EAM in its current form cannot be used to
implement IVI, because it forbids the use of differing suffix lengths:

   An EAM's IPv4 Prefix and IPv6 Prefix MUST have identical suffix
   lengths.  Any suffix bits MUST be kept intact during translation.

This conflicts with IVI, which allows for different suffix lengths (and
fixing up any discrepancy by padding any missing suffix bits with zero):

   Note that based on the IVI mapping mechanism, an IPv4 /24 is mapped
   to an IPv6 /64, and an IPv4 /32 is mapped to an IPv6 /72.

It should be possible to change SIIT-EAM such that it would be possible
to express IVI mappings with it too. Would you find that valuable?

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 9 Dec 2014 15:42:37 +0000

On Dec 9, 2014, at 2:35 AM, Tariq Saraj <[email-masked]> wrote:

> I don't understand the reason for discussion on SIIT when IVI is there. 

The issue is one of coupling to IPv4. In RFC 6145 (SIIT aka IVI), at least one of the addresses on a given machine has to be an RFC 6052 IPv4-embedded address, and that address (or a subnet containing it) has to be somewhere in routing. When IPv4 finally falls to the wayside, there is a remaining clean-up activity in the subject network, and until then, there is a slightly unnatural act in the IPv6 network due to the coupling. In Tore’s model, IPv6 is IPv6, IPv4 is IPv4, and the only coupling is a manual configuration in the translator. 

When he first ran the idea by the IETF, my viewpoint was that he was implementing what 6146 calls a “static translation”, and so was simply using RFC 6146. That’s not quite true, as 6146 is really a TCP/UDP session translator, not an IPv6/IPv4 translator. So, Tore is documenting an IPv6/IPv4 translator. Translation is the ply “unnatural act” in the deployment, and when IPv4 eventually falls to the wayside, the translator becomes out of date or disappears entirely, and nobody notices.