Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt

From: Richard Patterson <[email-masked]>
Date: Wed, 6 Jun 2018 13:25:00 +0100

Hi Jordi,

I'm not sure that I agree with requirement TRANS-2:
"The IPv6 Transition CE Router MUST verify if the WAN link supports
native IPv4.  In that case, transition mechanisms SHOULD NOT be
automatically enabled for that interface."

In fact I'd suggest the exact opposite, if a CE Router receives valid
S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP operations
until the WAN link status changes.  This could be expanded to include
a validation of a working IPv4aaS, but unsure how that should look.
For example, a brownfield IPv4aaS deployment is likely to still be
running dual stack in parallel whilst it migrates its clients to
IPv4aaS, the current wording would hinder this migration, by
preferring to stay on native (or NAT444) IPv4.

The "suspend" could also be debated, that it could be sufficient to
rely on the DHCPv4 back off mechanisms, but on a large network that
could still put a lot of extra load on the DHCPv4 server/relay and
RADIUS.   My vote is to suspend temporarily until reboot/WAN change.

And anecdotally, the current behaviour of OpenWRT is to prefer the S46
IPv4aaS mechanism, even when presented a valid DHCPv4 lease.

-Richard
On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ
<jordi.palet=[email-masked]> wrote:
>
> Hi Barbara,
>
> Sorry the late answer, last few weeks had been a non-stop traveling in 3 continents and too much work ...
>
> I see what you mean and we have discussed about this among the coauthors and amended the document, including some other comments received in the list.
>
> The new version has been published a few minutes ago:
>
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?include_text=1
>
> Basically, we are keeping a MUST for retail product versions, but not for specific ISP versions. I hope you agree with this, as we believe it makes sense.
>
> We don't update anymore the RFC7084, and we just use the same style to add the requirements for an IPv6 Transition CE Router (and we use this terminology across all the document).
>
> The main changes are summarized in the Annex C:
> 1.  ID-Nits: IANA section.
> 2.  ID-Nits: RFC7084 reference removed from Abstract.
> 3.  This document no longer updates RFC7084.
> 4.  UPnP section reworded.
> 5.  "CE Router" changed to "IPv6 Transition CE Router".
> 6.  Reduced text in Annex A.
>
> Hopefully everybody agrees now with this version, and in any case, will be very helpful if we can get any inputs.
>
> Regards,
> Jordi
>
>
>
> -----Mensaje original-----
> De: v6ops <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
> Fecha: lunes, 30 de abril de 2018, 19:20
> Para: V6 Ops List <[email-masked]>
> Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt
>
>     Hi Jordi,
>     I was having a hard time understanding where you were headed with proposed changes, by following the email thread. So I was waiting for this update. My company's email server also refuses to deliver to me some emails sent to this list without telling me. That probably adds to my difficulty.
>
>     My suggestion related to making requirements "MUST" were tied to also *not* making this an update to RFC 7084.
>
>     Here is the problem:
>     If this is an update to RFC 7084, then I cannot support any "MUST" statements.
>     My employer makes use of RFC 7084. As is. Updating RFC 7084 with additional "MUST" statements impacts my employer's ability to use and reference RFC 7084 to get the CE routers it wants. An RFC 7084 update with "MUST" statements (that are not needed by many current deployments) would be harmful to the existing IPv6 ecosystem.
>
>     For a device profile to be usable by the vendor and ISP community, it must contain "MUST" statements for all items that need to be required to achieve the profile's goal. Trying to get vendors to implement lots of "SHOULD" statements is futile. As an individual contributor, I do not support IETF publishing a futile device profile document with many "SHOULD" statements.
>
>     The solution I have proposed is to create a brand new device profile. A device profile for something called an "IPv6 Transition CE Router". This device profile is not an update to RFC 7084. It is its own thing. It is free to make use of RFC 7084 any way it wants -- not at all, in whole, or by referencing sections it does or doesn't want to require as part of the "IPv6 Transition CE Router" device profile.
>     Barbara
>
>     _______________________________________________
>     v6ops mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Jun 2018 14:33:14 +0200

Hi Richard,

This is an interesting perspective ...

What we prefer "the best quality" that dual-stack can offer, or even if you have lower quality, "push for IPv6" ?

Would not be better that if your network is offering already IPv4-as-a-service, you stop DHCPv4/PPP ?

I think that way, you, the ISP, have a better control for those customers that you want to provide "native-IPv4" vs transition.

I will like to heard what other people believes about this.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Richard Patterson <[email-masked]>
Fecha: miércoles, 6 de junio de 2018, 14:26
Para: "[email-masked] list" <[email-masked]>, <jordi.palet=[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt

    Hi Jordi,

    

    -Richard

---

From: Richard Patterson <[email-masked]>
Date: Wed, 6 Jun 2018 13:54:03 +0100

At the moment the current wording overrides the presence of DHCPv6 S46
Options, this prevents the ISP from doing a per-subscriber granular
migration. eg. by including it within a RADIUS Access-Accept Attribute
or not.

Disabling of the DHCPv4 server forces a big bang migration strategy;
The ISP may not have the luxury to upgrade all the CPE types on the
network to ones that support IPv4aaS method, so a big bang migration
wouldn't be feasible.

Regarding the quality argument, this makes the assumption that all
IPv4aaS methods mentioned are worse than native IPv4.  There's no
qualification on if that native IPv4 is actually behind NAT444 or not.
I'd say that if the ISP is returning valid S46 Options, then they want
or even expect the client to make use of them, not ignore them.

-Richard
On Wed, 6 Jun 2018 at 13:34, JORDI PALET MARTINEZ

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 6 Jun 2018 13:40:41 +0000

> migration. eg. by including it within a RADIUS Access-Accept Attribute or not.
> 
> Disabling of the DHCPv4 server forces a big bang migration strategy; The ISP
> may not have the luxury to upgrade all the CPE types on the network to ones
> that support IPv4aaS method, so a big bang migration wouldn't be feasible.
> 
> Regarding the quality argument, this makes the assumption that all IPv4aaS
> methods mentioned are worse than native IPv4.  There's no qualification on
> if that native IPv4 is actually behind NAT444 or not.
> I'd say that if the ISP is returning valid S46 Options, then they want or even
> expect the client to make use of them, not ignore them.
> 
> -Richard

I think I agree with Richard on this. If an ISP already has dual stack deployed and is starting deployment of an IPv4aaS technology, or has simultaneously deployed dual stack with IPv4aaS, then the goal must clearly be to move people to the IPv4aaS technology. If an ISP has IPv4aaS deployed, it is highly unlikely they will then deploy dual stack. So the presence of both dual stack and IPv4aaS must be an indication the ISP wants to move people off dual stack and onto IPv4aaS.

IPv4aaS should be the preferred connection in this case, in order to achieve a smoother transition. Note that IPv6 wasn't always "better" than IPv4 (it often had higher latency), but we still all agreed it should be "preferred". I think this is the same.
Barbara

> > I think that way, you, the ISP, have a better control for those customers
> that you want to provide "native-IPv4" vs transition.
> >
> > Para: "[email-masked] list" <[email-masked]>,
> > <jordi.palet=[email-masked]>
> > Asunto: Re: [v6ops] I-D Action:
> > draft-ietf-v6ops-transition-ipv4aas-00.txt
> >
> >     Hi Jordi,
> >
> >     > I see what you mean and we have discussed about this among the
> coauthors and amended the document, including some other comments
> received in the list.
> >     >
> >     > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dtransition-
> 2Dipv4aas_-3Finclude-5Ftext-3D1&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=4mLE38cbhG6IbVnIC_-HCq-BqZC-
> 1QkWKcGmMSW2ebo&s=Gfrg561zGQIbQ4WjA7jTTQgT7zNcGfY1kQ5EGlq2kL
> U&e=
> >     >
> >     > Basically, we are keeping a MUST for retail product versions, but not for
> specific ISP versions. I hope you agree with this, as we believe it makes
> sense.
> >     >
> >     > We don't update anymore the RFC7084, and we just use the same style
> to add the requirements for an IPv6 Transition CE Router (and we use this
> terminology across all the document).
> >     >
> >     > Hopefully everybody agrees now with this version, and in any case, will
> be very helpful if we can get any inputs.
> >     >
> >     > Regards,
> >     > Jordi
> >     >
> >     >
> >     >
> >     >     I was having a hard time understanding where you were headed with
> proposed changes, by following the email thread. So I was waiting for this
> update. My company's email server also refuses to deliver to me some
> emails sent to this list without telling me. That probably adds to my difficulty.
> >     >
> >     >     My suggestion related to making requirements "MUST" were tied to
> also *not* making this an update to RFC 7084.
> >     >
> >     >     Here is the problem:
> >     >     My employer makes use of RFC 7084. As is. Updating RFC 7084 with
> additional "MUST" statements impacts my employer's ability to use and
> reference RFC 7084 to get the CE routers it wants. An RFC 7084 update with
> "MUST" statements (that are not needed by many current deployments)
> would be harmful to the existing IPv6 ecosystem.
> >     >
> >     >     For a device profile to be usable by the vendor and ISP community, it
> must contain "MUST" statements for all items that need to be required to
> achieve the profile's goal. Trying to get vendors to implement lots of
> "SHOULD" statements is futile. As an individual contributor, I do not support
> IETF publishing a futile device profile document with many "SHOULD"
> statements.
> >     >
> >     >     The solution I have proposed is to create a brand new device profile.
> A device profile for something called an "IPv6 Transition CE Router". This
> device profile is not an update to RFC 7084. It is its own thing. It is free to
> make use of RFC 7084 any way it wants -- not at all, in whole, or by
> referencing sections it does or doesn't want to require as part of the "IPv6
> Transition CE Router" device profile.
> >     >     Barbara
> >     >
> >     >     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=4mLE38cbhG6IbVnIC_-HCq-BqZC-
> 1QkWKcGmMSW2ebo&s=IfRxZ7pJ-2I-
> LI4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=
> >     >
> >     >
> >     >
> >     >
> >     > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.consulintel.es&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=4mLE38cbhG6IbVnIC_-HCq-BqZC-
> 1QkWKcGmMSW2ebo&s=y7RBDVf9Thf5nLmISjH_vjV9GfSNXTfnTqVQjIm2Kp
> A&e=
> >     > 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.
> >     >
> >     >
> >     >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_v6ops&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8T
> > q4vrfog&m=4mLE38cbhG6IbVnIC_-HCq-BqZC-
> 1QkWKcGmMSW2ebo&s=IfRxZ7pJ-2I-LI
> > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_v6ops&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8T
> > q4vrfog&m=4mLE38cbhG6IbVnIC_-HCq-BqZC-
> 1QkWKcGmMSW2ebo&s=IfRxZ7pJ-2I-LI
> > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=
> >
> >
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.consulintel.es
> > &d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=4mLE38cb
> > hG6IbVnIC_-HCq-BqZC-
> 1QkWKcGmMSW2ebo&s=y7RBDVf9Thf5nLmISjH_vjV9GfSNXTfn
> > TqVQjIm2KpA&e=
> > 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.
> >
> >
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_v6ops&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8T
> > q4vrfog&m=4mLE38cbhG6IbVnIC_-HCq-BqZC-
> 1QkWKcGmMSW2ebo&s=IfRxZ7pJ-2I-LI
> > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=4mLE38cbhG6IbVnIC_-HCq-BqZC-
> 1QkWKcGmMSW2ebo&s=IfRxZ7pJ-2I-
> LI4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Jun 2018 15:41:01 +0200

Below in-line.

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Richard Patterson <[email-masked]>
Fecha: miércoles, 6 de junio de 2018, 14:55
Para: "[email-masked] list" <[email-masked]>, <jordi.palet=[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt

If you stop DHCPv4/PPP for specific customers, you have the same per-subscriber control, right ?

Yeah, if you compare the quality of IPv4 with NAT444.

The problem I see if we change this behavior is that S46 only provides a solution for some of the transition mechanism, not all, so for example, 464XLAT will not be able to work if we don't follow the current suggested approach.
    
    -Richard

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Jun 2018 15:49:37 +0200

I see now the point, if you have already dual-stack ... 

I think this (removing TRANS-2) may work then:

General transition requirements:

   TRANS-1:  If more than one S46 mechanism is supported, the IPv6
             Transition CE Router MUST support the DHCPv6 S46 priority
             option described in [RFC8026] (Unified IPv4-in-IPv6
             Softwire Customer Premises Equipment (CPE): A DHCPv6-Based
             Prioritization Mechanism).

   TRANS-2:  If 464XLAT [RFC6877] is
             supported, the IPv6 Transition CE Router MUST enable the
             CLAT (in order to automatically configure 464XLAT
             [RFC6877]).  If 464XLAT [RFC6877] is not supported, and
             more than one S46 mechanism is supported, following
             Section 1.4 of [RFC8026], MUST check for a valid match in
             OPTION_S46_PRIORITY, which will allow configuring any of
             the other transition mechanisms.

If we agree on this text, I can upload a new version with this change in a couple of days, unless there are new inputs in this part or others ...

Regards,
Jordi

---

From: Richard Patterson <[email-masked]>
Date: Wed, 6 Jun 2018 15:41:05 +0100

That would address my concern.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Jun 2018 17:21:59 +0200

>              the other transition mechanisms.
    
    I think the comingling of "supported" and "enabled" is problematic in this requirement. 
    "Supported" means (to most people) the same as "implemented". That is, the code exists. "Enabled" means the supported code is actually running. Just because 464XLAT is supported does not mean it is enabled. If 464XLAT is not enabled, then it may not be a good idea to automatically enable CLAT. And, likewise, the other mechanisms should only be configured if they are enabled and not merely supported. I suggest changing all instances of "supported" to "enabled" in this requirement.

-> That's why the requirement is, using other words: If 464XLAT is implemented in this CE, enable it (by means of enabling the CLAT). I'm talking here only in the CE, because the S46 doesn't include support for 464XLAT, so we can't use it to check it ...

    I haven't gone through the entire document yet, but you may want to look for other cases where you use "supported" where you really should use "enabled". TRANS-1 is fine because it really is just talking about ensuring the code exists (is implemented) on the device. You may also want to consider requirements for conditions under which some of the supported features are automatically enabled. For example, for 464XLAT, should PCP (if implemented) be automatically enabled when 464XLAT is enabled? Or when CLAT is enabled?

-> Will do, anyway, I can wait a few extra days if you will have time to do an in-depth review of the document?
    
    We may also want to consider whether to recommend that a Transition CE Router by default has all these mechanisms enabled. There should probably also be a requirement that indicates it should be possible to enable/disable any of these mechanisms. At this stage if the game, we need to be sure we can defend against brokenness. 

-> I think in the case of all the other transition, this can be done by means of S46, but will review again this point, just in case something else need to be suggested/amended. Of course, in general I expect the CEs to implement in the CLI or GUI, or other management interfaces (as they do today) a way to explicitly disable/enable a mechanism. Do you think we should have that as an explicit requirement?

    Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 6 Jun 2018 16:01:42 +0000

>     "Supported" means (to most people) the same as "implemented". That is,
> the code exists. "Enabled" means the supported code is actually running. Just
> because 464XLAT is supported does not mean it is enabled. If 464XLAT is not
> enabled, then it may not be a good idea to automatically enable CLAT. And,
> likewise, the other mechanisms should only be configured if they are
> enabled and not merely supported. I suggest changing all instances of
> "supported" to "enabled" in this requirement.
> 
> -> That's why the requirement is, using other words: If 464XLAT is
> implemented in this CE, enable it (by means of enabling the CLAT). I'm talking
> here only in the CE, because the S46 doesn't include support for 464XLAT, so
> we can't use it to check it ...

Are you saying:
(1) If 464XLAT is implemented, the default configuration MUST have CLAT enabled.
(2) If 464XLAT is implemented, then CLAT MUST always be enabled and there MUST be no way to disable it.
While I think (1) may be ok, I think (2) is an incredibly bad idea. As you describe it, the requirement reads more like (2) than (1).
  
>     I haven't gone through the entire document yet, but you may want to look
> for other cases where you use "supported" where you really should use
> "enabled". TRANS-1 is fine because it really is just talking about ensuring the
> code exists (is implemented) on the device. You may also want to consider
> requirements for conditions under which some of the supported features
> are automatically enabled. For example, for 464XLAT, should PCP (if
> implemented) be automatically enabled when 464XLAT is enabled? Or when
> CLAT is enabled?
> 

I may not have time. I have to focus on other priorities for the next couple of weeks.
 
>     We may also want to consider whether to recommend that a Transition CE
> Router by default has all these mechanisms enabled. There should probably
> also be a requirement that indicates it should be possible to enable/disable
> any of these mechanisms. At this stage if the game, we need to be sure we
> can defend against brokenness.
> 
> -> I think in the case of all the other transition, this can be done by means of
> S46, but will review again this point, just in case something else need to be
> suggested/amended. Of course, in general I expect the CEs to implement in
> the CLI or GUI, or other management interfaces (as they do today) a way to
> explicitly disable/enable a mechanism. Do you think we should have that as
> an explicit requirement?

Yes, it should be an explicit requirement. If the intent of an "enabled" statement is to have it enabled as default configuration, then the phrase "default configuration" needs to be used. In cases where there is a trigger that causes a function to become enabled, it needs to be clear what the trigger is. Mere presence of code (implementation) should never be such a trigger. But presence of code is reasonable as something that can impact default configuration.
 
Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Jun 2018 18:15:23 +0200

Are you saying:

-> Right now, is 2. Because we don't have an explicit way to check if 464XLAT is being used by the ISP by means of S46 (one possibility will be to update S46 to support 464XLAT), but we can make it this way:

[RFC6877]), unless an alternative S46 mechanism is supported, 
and following

     
    > explicitly disable/enable a mechanism. Do you think we should have that as

Clear, then will draft a requirement for this:

    Barbara

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Jun 2018 10:01:32 -0700

Color me wacko. I'm thinking about weird cases.

No hats.

Suppose I enable dual stack in a domain, and the router in question as a result turns off transition stuff. Then IPv6 connectivity fails.

Suppose the domain is IPv4-only, and native IPv6 gets turned on. Does the transition technology stop?

Let your mind spin for a while.

This seems like a problem that should be solved using routing. If I don't have a route to <somewhere> using native IPv6 but do using the transition technology, I have an argument for the transition technology. If the native route becomes available, I should think it would supersede the transition path.

Am I missing something?

> On Jun 6, 2018, at 5:25 AM, Richard Patterson <[email-masked]> wrote:
> 
> Hi Jordi,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 06 Jun 2018 19:20:54 +0200

Hi Fred,

Below in-line.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Fred Baker <[email-masked]>
Fecha: miércoles, 6 de junio de 2018, 19:02
Para: Richard Patterson <[email-masked]>, JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt

    No hats.

    

-> See the example from Barbara. You have dual-stack today. You want to start moving "some" customers to IPv4aas. So, you will have "both" routings working in that "region". That's why it looks like DHCP options are more sensible in this case and "considering" that the future is IPv6-only (and IPv4aas is a temporary measure), the *preference* should be for the transition route instead of the native-one (if both of them are available).
    
    Am I missing something?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 6 Jun 2018 15:03:48 +0000