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

[Tariq Saraj <[e-mail]>]

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, <[e-mail]> wrote:

> Send v6ops mailing list submissions to
>         [e-mail]
>
> 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
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> 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 <[e-mail]>
> To: Ca By <[e-mail]>
> Cc: IPv6 Ops WG <[e-mail]>
> 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 <[e-mail]>
> To: Ca By <[e-mail]>
> Cc: IPv6 Ops WG <[e-mail]>
> Date: Mon, 8 Dec 2014 09:42:53 +0100
> Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-01
> * Ca By <[e-mail]>
>
> > 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 <[e-mail]>
> To: Brian E Carpenter <[e-mail]>
> Cc: "[e-mail] WG" <[e-mail]>
> 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 <[e-mail]>
> To: Tore Anderson <[e-mail]>
> Cc: IPv6 Ops WG <[e-mail]>
> 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 <[e-mail]> wrote:
>
>> * Ca By <[e-mail]>
>>
>> > 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" <[e-mail]>
> To: Jeroen Massar <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 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
> [e-mail]
>
>
> > -----Original Message-----
> > From: v6ops [mailto:[e-mail]] On Behalf Of Templin, Fred L
> > Sent: Saturday, December 06, 2014 8:18 AM
> > To: Jeroen Massar; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> >
> > Hi Jeroen,
> >
> > > -----Original Message-----
> > > From: v6ops [mailto:[e-mail]] On Behalf Of Jeroen Massar
> > > Sent: Saturday, December 06, 2014 4:26 AM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> > >
> > > On 2014-12-06 12:20, [e-mail] 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
> > [e-mail]
> >
> > > Greets,
> > >  Jeroen
> > >
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> ---------- Forwarded message ----------
> From: The IESG <[e-mail]>
> To: IETF-Announce <[e-mail]>
> Cc: v6ops mailing list <[e-mail]>, v6ops chair <
> [e-mail]>, RFC Editor <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>


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