Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

Fernando Frediani <fhfrediani@gmail.com> Wed, 08 January 2020 14:45 UTC

Return-Path: <fhfrediani@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F819120114 for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2020 06:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ8GU5Y0_pGU for <v6ops@ietfa.amsl.com>; Wed, 8 Jan 2020 06:45:35 -0800 (PST)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B29120044 for <v6ops@ietf.org>; Wed, 8 Jan 2020 06:45:35 -0800 (PST)
Received: by mail-qt1-x834.google.com with SMTP id d18so2932961qtj.10 for <v6ops@ietf.org>; Wed, 08 Jan 2020 06:45:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=idARoa0EyLBm6nzktUo2vhObbX4+Mrksz0mzkzl5QW8=; b=CP0KUSl1z+/qGbgPt8Sd9meabO4fhYDJKP4jk4n7ONWEvA009aecga6Dw8k4a874bm CgtcfSz0KrBQvAfhltEEtMtkvGvVVIIaOMD8ZvauUkMCs6OWPk8XplOajC4armyCLMI6 tncXqS9A9QwaTaA0wSYOJcEM2K/5fpzwZ1YJCbOACbybPlwlbXO9POY2N7vZXmp/CVX2 q5fzRdkOfUVutGd26MEvB6aytWNdA0w05j0b22zlF5bIp3joWKc64/wqXWKdAHo2gx8C ITP+VyciA14TwQ/zJsOSZdjOLLPqYdcgKiP0Derco6W4Lsn+xCVPNNnqhhiCbjfKwOcK BxOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=idARoa0EyLBm6nzktUo2vhObbX4+Mrksz0mzkzl5QW8=; b=Vpa/iF09LvSzCnYRJQzyS84q6weEm+gbIo/W0bGMtZLg9xbF5FFVfMUuf7YDzeSGLq UvcOKHa6Ufa4nUgGn6IoYMUgfE26ttngSUZWFoyqMI/R3yZebEqMGqrUWeMP4yBpxrHE YbEjTKHrjOyk4HhlXssau/K3FvkW/Iz1RHRmZS+yBgbbVTkAgwSv8kf5py3a9LYUmIWd Of3aILsEDRIa6XLEpK3sD0zl68SL5N/dtdJKpltiTfEOh424kkndgJhbYeX35JrCDvxK TChXOo5kIO5Ka5X1h4SUucjcZbEj7A+BL8zjYfXeKDpDcTPgTKxtkNvYxXwCdHUYySRT Sz/A==
X-Gm-Message-State: APjAAAVlbSa8srZ7LEIYPLLiWDCuzQcD1WdRhd+5ac1ZWCZF5pZuGUZj 3zg1OdW25TrDPuT0ApGDPlqJi6Q2
X-Google-Smtp-Source: APXvYqxy+njFr3xIIhHFfWpsvg4vSdCPRWyul1XJjwjUeGSeWjlH5mdK4k0jaUACyJ5kJ+PDsc0rUg==
X-Received: by 2002:ac8:1851:: with SMTP id n17mr3883141qtk.305.1578494734038; Wed, 08 Jan 2020 06:45:34 -0800 (PST)
Received: from [192.168.10.100] ([201.82.45.199]) by smtp.gmail.com with ESMTPSA id y18sm1475821qki.0.2020.01.08.06.45.32 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 06:45:33 -0800 (PST)
To: v6ops@ietf.org
References: <FFB9FE6E-D2D2-46A2-8F2A-DB4E5534FE3E@consulintel.es> <2020010616354842655859@chinatelecom.cn> <3d68d660-0b61-cfe3-43e7-14563c47413d@gmail.com> <2020010722094585159928@chinatelecom.cn> <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es>
From: Fernando Frediani <fhfrediani@gmail.com>
Message-ID: <03db5441-ae0d-7813-7b65-1bfd37a36805@gmail.com>
Date: Wed, 08 Jan 2020 11:45:29 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <4A39BB6A-6711-4B31-8122-3698FDD4AAAB@consulintel.es>
Content-Type: multipart/alternative; boundary="------------EA8FCC0E478D8FC66514BB06"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/cmOv4dNb1zSrioQ8mRwwbRKvvvQ>
Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2020 14:45:42 -0000

Actually, there is yet another advantage if this proposal passes:

- As traffic which originally would be IPv4-only (due to the legacy 
devices), if it's able to be 'converted' to IPv6 at the CPE for IPv6 
supported destinations this means less logging for law enforcement for 
all the stuff that would connect to the external world via the PLAT IPv4 
addresses, meaning less storage, less log indexing and less people's time.

Regards
Fernando

On 08/01/2020 11:11, JORDI PALET MARTINEZ wrote:
>
> Hi Chongfeng,
>
> In 464XLAT, the way you allocate ports to customers in the NAT64 is 
> typically much more efficient than in pre-allocation as done commonly 
> in CGN or even MAP.
>
> So, you get ports “as you need them”. This means that you’re, by 
> default, making a better usage of each of the IPv4 addresses.
>
> We have discussed this in
>
> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison
>
> Also, it means that you’re not restricted to a given number of ports 
> per subscriber.
>
> Regards,
>
> Jordi
>
> @jordipalet
>
> El 7/1/20 15:10, "v6ops en nombre de xiechf@chinatelecom.cn 
> <mailto:xiechf@chinatelecom.cn>" <v6ops-bounces@ietf.org 
> <mailto:v6ops-bounces@ietf.org> en nombre de xiechf@chinatelecom.cn 
> <mailto:xiechf@chinatelecom.cn>> escribió:
>
> Hi,Fernando,
>
> Thank you for your comments.  You mentioned that 464XLAT is able to 
> save more IPv4 addresses, I think this is based on the comparison with 
> dual-stack approach, such as NAT44. Have you ever done some 
> quantitative analysis of  how much percentage of IPv4 addesses can be 
> saved with 464XLAT? Thank you!
>
> Best regards
>
> Chongfeng
>
>     *From:*Fernando Frediani <mailto:fhfrediani@gmail.com>
>
>     *Date:* 2020-01-07 00:00
>
>     *To:*v6ops <mailto:v6ops@ietf.org>
>
>     *Subject:* Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches
>     **Call for Adoption**
>
>     On 06/01/2020 05:35, xiechf@chinatelecom.cn
>     <mailto:xiechf@chinatelecom.cn> wrote:
>
>         2\ Based on my experience, I think the possibility of XLAT to
>         be used in wireline network is very small, Is there any
>         large-scale ISP who plan to use XLAT for wireline broadband?
>         Nearly every IPv6-capable CPE is dual stack, it is very
>         difficult to convince the CPE industry to support XLAT in the
>         forseen future. Another factor that we should consider is that
>         the IPTV service of some ISPs is carried in a seperate
>         layer-two channle, which does not mix with the default
>         Internet access traffic.
>
>     Although the biggest challenge for 464XLAT adoption in fixed
>     broadband ISPs is the lack of CLAT client on most CPEs I don't
>     think that would be a major issue to convince CPE industry to have
>     it because technically speaking is a minor component of the
>     firmware and quiet easy to add de daemon. Sure it takes some time
>     to happen, but it's not a major thing really.
>     With this happening I bet in the future there is a potential of
>     ISPs replacing CGNAT + IPv6 scenarios for 464XLAT for its
>     advantages specially in being able to save more Public IPv4 addresses.
>
>     With regards the IPTV service of some ISPs it occurs inside the
>     ISP backbone and in most cases wouldn't require any kind of
>     translation on the ISP side.
>
>     Regards
>     Fernando Frediani
>
>             *From:*JORDI PALET MARTINEZ
>             <mailto:jordi.palet=40consulintel.es@dmarc..ietf.org>
>
>             *Date:* 2020-01-06 04:56
>
>             *To:*v6ops@ietf.org list <mailto:v6ops@ietf.org>
>
>             *Subject:* Re: [v6ops]
>             draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
>
>             Hi Fernando,
>
>             Adding some inputs, below, in-line (->).
>
>             El 4/1/20 4:34, "v6ops en nombre de Alejandro D'Egidio"
>             <v6ops-bounces@ietf.org en nombre de
>             adegidio=40telecentro.net.ar@dmarc.ietf.org>
>             <mailto:v6ops-bounces@ietf.orgennombredeadegidio=40telecentro.net.ar@dmarc..ietf.org>
>             escribió:
>
>             Hello Fernando,
>
>             First at all, thanks for your support to the work and the
>             document and for taking your time to read all the document.
>
>             I will try to answer your comments below.
>
>             Regards,
>
>             Alejandro
>
>             ----- Mensaje original -----
>
>             > De: "Fernando Gont" <fgont@si6networks.com>
>             <mailto:fgont@si6networks.com>
>
>             > Para: "Ron Bonica"
>             <rbonica=40juniper.net@dmarc.ietf.org>
>             <mailto:rbonica=40juniper.net@dmarc.ietf.org>,
>             "v6ops@ietf.org list" <mailto:v6ops@ietf.orglist>
>             <v6ops@ietf.org> <mailto:v6ops@ietf.org>
>
>             > Enviados: Viernes, 3 de Enero 2020 20:40:11
>
>             > Asunto: Re: [v6ops]
>             draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**
>
>             > Folks,
>
>             >
>
>             > I've read the document, and have the following comments:
>
>             >
>
>             > It would seem to me is that this document has resulted
>             from an
>
>             > operators' concern that deployment of 464xlat might
>             result in
>
>             > unnecessary heavyweight use of the stateful PLAT,
>             leading to scalability
>
>             > problems or unnecessary money spendings. In that sense,
>             I would like the
>
>             > issue to be documented (even if somehow we don't agree
>             on a workaround).
>
>             Yes, from one point of view it is correct what you said
>             and in addition to that we have an unnecessary second
>             translation (NAT64) when customer traffic was translated
>             to IPv6 (NAT46) and the destination (content) is available
>             in IPv6 also, so we could avoid both a bottleneck and a
>             performance impairment. That's why we consider this as an
>             optimization.
>
>             -> I think the document is doing the work of documenting
>             the problem statement and providing possible solutions,
>             which the idea of choosing one. We understand that 464XLAT
>             was not designed having this scenario in mind, but if we
>             can find a good solution, is worth to solve it.
>             Furthermore, if the WG agree that this is the way to go,
>             we could update with this document 464XLAT (which is an
>             informational one) and make it to the standards track. As
>             I've already expressed several times, it is pity that
>             being the transition mechanism that is more used in the
>             world (versus all the others, in terms of number of
>             devices), it is not a standard.
>
>             >
>
>             > So I support the adoption of this document (or some
>             version of it) --
>
>             > i.e., there's value in documenting the issue itself.
>
>             >
>
>             > That said, I think that further work is required on the
>             document. PLease
>
>             > find my review below:
>
>             >
>
>             >
>
>             > **** Some meta comments ****
>
>             >
>
>             > * Meta: I'd put more stress on why this "optimization"
>             is important. You
>
>             > delve into many other (rather unnecessary) details, but
>             don't elaborate
>
>             > much regarding why this "optimization" is important.
>
>             -> My reading is that the optimization and the need for it
>             is well described, but definitively will take a look into
>             it and improve it if needed.
>
>             Yes, it is true, maybe the introduction could be simpler
>             and more oriented to show the concrete problem and why we
>             believe this is important.
>
>             I don't know if the info is wrong, maybe a specific
>             initial summary that indicates it is missing. We can
>             consider it.
>
>             >
>
>             > * Meta: It'd be important to note that, according to the
>             Abstract of
>
>             > RFC6877, 464XLAT assumes IPv4 services over an IPv6-only
>             node. In that
>
>             > sense, the behavior you describe is kind of "expected",
>             and what you
>
>             > describe would seem to me more of a mechanism to *opt
>             out of 464xlat*
>
>             > than an optimization to 464XLAT itself.
>
>             -> Yes, I said that in my first comment. With this
>             optimization, if we are able to find consensus in a good
>             solution, we improve something that was not initially
>             expected to be done by 464XLAT. I don't see the "opt-out"
>             point that you mention.
>
>             Yes, 464XLAT asumes both IPv4 services and IPv4-only
>             devices also.
>
>             Yes, this is the expected behavior of 464XLAT (and MAP-T
>             also) but from a practical and performance point of view,
>             maybe, it is not the most optimal path for the end-to-end
>             traffic flow. As you said if we avoid the NAT64,
>             technically speaking, the traffic will not be going
>             through a 464XLAT/MAP-T scenario.
>
>             We are not saying that 464XLAT is wrong at all, we are
>             trying to expose a real problem for IPv6 only network
>             deployments and trying to present some approaches to solve
>             it (or minimize it)..
>
>             >
>
>             > * It would seem to me that the cases where this issue is
>             more of a
>
>             > concern is essentially smartboxes (smart TVs) consuming
>             media from large
>
>             > CDNs. If so, this should be spelled out, since this
>             essentially sets the
>
>             > context for what options/approaches can be considered
>             acceptable.
>
>             Ok, yes, we can put more effort to explain that.
>
>             >
>
>             >
>
>             >
>
>             > *** Some specific comments: ****
>
>             >
>
>             > * Abstract: I'm curious if the term "NAT46" can be
>             confusing, for
>
>             > multiple reasons (for instance, it's not specified in
>             RFC7915). Just use
>
>             > "SIIT", and the context (i.e., describe what's on each
>             side of the SIIT
>
>             > device, and what's the intent).
>
>             -> Initially we were using the term CLAT, but then we
>             realized that MAP-T has the same issue, and there it is
>             not called CLAT, but NAT46. This is the reason, quite
>             simple, because the optimization will also work for MAP-T.
>
>             We can review it if it is confusing.
>
>             The idea on this point was to talk about the NAT46 of CPE
>             (CLAT).
>
>             Yes, RFC7915 talks about SIIT independently if it is NAT46
>             or not.
>
>             Regarding "(IP/ICMP Translation Algorithm) as described by
>             [RFC7915]" it refers just to SIIT.
>
>             As we know, CLAT is a combination of NAT46 + SIIT because
>             it's an stateless translation from IPv4 to IPv6.
>
>             >
>
>             >
>
>             > * Introduction:
>
>             > It seems to me the intro contains too many unnecessary
>             details. e.g.,
>
>             > just talk about the CLAT as an abstract concept. Where/how
>
>             > (specifically) it is implemented is mostly irrelevant in
>             the context of
>
>             > this document.
>
>             Yes, I don't know, it could be, as I put above maybe in
>             the introduction we talk about many specific things and we
>             could talk more about the problem itself.
>
>             >
>
>             >
>
>             > * Section 4:
>
>             > Is the option where packets might get to the Cache with
>             *private space*
>
>             > worth mentioning/describing/discussing?
>
>             -> When we talked with CDN/cache providers, they don't
>             like to use non-GUA (example the NAT64 WKP), so it is
>             discussed as an option in approach 1.
>
>             I'm sorry I didn't understand it very well.
>
>             What *private space* are you talking about? IPv4 or IPv6?
>
>             If you are talking about IPv6, CDNs normally have IPv6 GUA.
>
>             If you are talking about customers with private IPv4
>             reaching public IPv4 destination CDNs, yes we could
>             explain it because it is the main scenario we actually
>             some content providers offers to ISPs to deliver content
>             from public IPv4 of CDN to customers with private IPv4
>             avoiding a CGN platform. That was the first reason to
>             create this document.
>
>             >
>
>             >
>
>             > * Section 4.3:
>
>             >   One more advantage of this solution is that the EAMT
>             pairs doesn't
>
>             >   need to match the "real" IPv4/IPv6 addresses available
>             in the A/AAAA
>
>             >   records, as shown in the next example.
>
>             >
>
>             > Please elaborate.
>
>             -> I think it is clear if you look at the example.
>
>             >
>
>             >
>
>             > * Section 5:
>
>             >   If NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) is
>             chosen, it can
>
>             >   be complemented to resolve this issue, by means of
>             making sure that
>
>             >   IPv6-only destinations have one A resource record
>             (even an invalid
>
>             >   one), despite they aren't actually connected to IPv4.
>
>             >
>
>             > Not sure what you mean.
>
>             -> I think it is clear if you read the paragraph before
>             that one. Otherwise we could expand the text to make it
>             more obvious.
>
>             It's an idea, we offer different ideas (approaches) to try
>             optimize the traffic flow.
>
>             Here, the idea is that if the destination is IPv6-only,
>             when we have an IPv4-only device, in a normal case you
>             could never reach the destination but if you have this
>             optimization your Proxy DNS could detect that it doesn't
>             have an A record but it has an AAAA record, so you could
>             be connected to the IPv6 destination. Without this, your
>             IPv4-only device would not be able to get the IPv6-only
>             content.
>
>             >
>
>             >
>
>             > * Section 5:
>
>             >   In fact, it may become an incentive for the IPv6
>             deployment in
>
>             >   Internet services and provides the option to use an
>             IPv4 address
>
>             >   (maybe anycast) for the "non-valid" A resource record,
>             that points to
>
>             >   a "universal" web page (maybe hosted by IETF?) that
>             displays a
>
>             >   warning such as "Sorry, you don't IPv6 support in your
>             operator, so
>
>             >   this service is not available for you".
>
>             >
>
>             > Please *no*, for so many different reasons. -- including
>             "the average
>
>             > user doesn't care about IPv6, and may not even be aware
>             of what it is".
>
>             -> It can be a different text not necessarily mention IPv6
>             but just "your Internet connection is not able to access
>             this content, please ask your ISP to upgrade it". Anyway,
>             it is very contentious topic ... This probably will get
>             removed in a new version, or moved to an annex, etc.
>
>             Ok, it could be, but remember it is another proposal like
>             the other approaches and the idea is to get these kind of
>             inputs.
>
>             >
>
>             >
>
>             >
>
>             > * Section 6:
>
>             >   Should we recommend having A records for IPv6-only
>             services in
>
>             >   Internet?  The A record may point to a "reserved" or
>             "special" IPv4
>
>             >   address..  A web page IPv4-only hosted by IETF(?)
>             showing "sorry this
>
>             >   web page/service is only available from IPv6 enabled
>             operators"?.
>
>             >
>
>             > Please no. This assumes (?) hosts prefer IPv6, but they
>             don't need to.
>
>             > In which case they would get to such page and have a not
>             so great
>
>             > WTH(!?) moment.
>
>             >
>
>             >
>
>             >
>
>             > * Section 6:
>
>             >   NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems
>             the right
>
>             >   solution for optimizing the access to dual-stack
>             services, whether
>
>             >   they are located inside or outside the ISP.
>
>             >
>
>             > It would seem to me that, actually, Approach #3, when
>             the ISP has no
>
>             > control on the CDN, or approach #1 (when it does), are
>             the way to go.
>
>             > Approach #2 seems rather complex, with the consequent
>             opportunities to
>
>             > screw up.
>
>             Approach #1 is not easy to be implemented because content
>             providers doesn't want to be envolved on this process
>             despite agreeing it can be an improvement , so the don't
>             want to do any change in configuration of their devices /
>             interfaces. It applies more in case where CDN is
>             controlled by ISP (own CDN), but we want to define a
>             general solution, we need to consider the normal case of
>             public / external CDNs.
>
>             Approach #3, as you say, it is when ISP doesn't have
>             control of the CDN. This is could not be a very scalable
>             solution because it's not dynamic and any change needs to
>             be propagated to all CPEs. On the other hand it's a very
>             easy method to make a fast deploy where there are not
>             often changes. I think this is a way where that allow to
>             the operator to deploy the solution quickly without
>             depending on complex mechanisms and where content provider
>             doesn't change DNS records, this is the case of Netflix
>             CDN where A and AAAA records always have the same IPs
>             associated for the same FQDN (for CDN).
>
>             Approach #2, yes, clearly it is more complex but it will
>             depends on how much complexity we want to give to the
>             process and we need to define very well which cases we
>             want to consider.
>
>             >
>
>             >
>
>             > * Section 6:
>
>             >   SIIT already has a SHOULD for EAM support.  Should
>             464XLAT be updated
>
>             >   by this document so the CLAT has a MUST for EAM support?.
>
>             >
>
>             > 464xlat employs existing technologies. So I'm not sure
>             you can do a MUST
>
>             > in 464xlat, when it relies on SIIT, and for SIIT the
>             requirement is a
>
>             > SHOULD.
>
>             Yes, what you say is valid, these are questions to see
>             exactly what the community thinks.
>
>             >
>
>             > Besides, the 464xlat spec does not even employ RFC2119
>             language.
>
>             >
>
>             >
>
>             >
>
>             > * Section 7:
>
>             >
>
>             > Any solution where you spoof DNS records would play bad
>             with DNSsec.
>
>             > This should at least be discussed.
>
>             >
>
>             >
>
>             > Thanks!
>
>             >
>
>             > Cheers,
>
>             > Fernando
>
>             >
>
>             >
>
>             >
>
>             >
>
>             > On 11/12/19 14:24, Ron Bonica wrote:
>
>             >> Folks,
>
>             >>
>
>             >>
>
>             >>
>
>             >> Each week between now and IETF 107, we will review and
>             discuss one draft
>
>             >> with an eye towards progressing it.
>
>             >>
>
>             >>
>
>             >>
>
>             >> This week, please review and comment on
>
>             >> draft-palet-v6ops-464xlat-opt-cdn-caches.
>
>             >>
>
>             >>
>
>             >>
>
>             >> When reviewing this draft, please indicate whether you
>             think that V6OPS
>
>             >> should adopt it a s a work item.
>
>             >>
>
>             >>
>
>             >>
>
>             >>                                                      
>             Fred and Ron
>
>             >>
>
>             >>
>
>             >>
>
>             >>
>
>             >> Juniper Business Use Only
>
>             >>
>
>             >>
>
>             >> _______________________________________________
>
>             >> v6ops mailing list
>
>             >> v6ops@ietf.org <mailto:v6ops@ietf.org>
>
>             >> https://www.ietf.org/mailman/listinfo/v6ops
>
>             >>
>
>             >
>
>             >
>
>             > --
>
>             > Fernando Gont
>
>             > SI6 Networks
>
>             > e-mail: fgont@si6networks.com <mailto:fgont@si6networks.com>
>
>             > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55
>             1D4E 7492
>
>             >
>
>             >
>
>             >
>
>             >
>
>             > _______________________________________________
>
>             > v6ops mailing list
>
>             > v6ops@ietf.org <mailto:v6ops@ietf.org>
>
>             > https://www.ietf.org/mailman/listinfo/v6ops
>
>             _______________________________________________
>
>             v6ops mailing list
>
>             v6ops@ietf.org <mailto:v6ops@ietf.org>
>
>             https://www.ietf.org/mailman/listinfo/v6ops
>
>             **********************************************
>
>             IPv4 is over
>
>             Are you ready for the new Internet ?
>
>             http://www.theipv6company.com
>
>             The IPv6 Company
>
>             This electronic message contains information which may be
>             privileged or confidential. The information is intended to
>             be for the exclusive use of the individual(s) named above
>             and further non-explicilty authorized disclosure, copying,
>             distribution or use of the contents of this information,
>             even if partially, including attached files, is strictly
>             prohibited and will be considered a criminal offense. If
>             you are not the intended recipient be aware that any
>             disclosure, copying, distribution or use of the contents
>             of this information, even if partially, including attached
>             files, is strictly prohibited, will be considered a
>             criminal offense, so you must reply to the original sender
>             to inform about this communication and delete it.
>
>             _______________________________________________
>
>             v6ops mailing list
>
>             v6ops@ietf.org <mailto:v6ops@ietf.org>
>
>             https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>         _______________________________________________
>
>         v6ops mailing list
>
>         v6ops@ietf.org  <mailto:v6ops@ietf.org>
>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________ v6ops mailing list 
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents of 
> this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you 
> are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited, will be 
> considered a criminal offense, so you must reply to the original 
> sender to inform about this communication and delete it.
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops