Re: [sunset4] Sunset4 work

[Carlos M. Martinez]

Hi all,

do you know if this hum is happening ?

-Carlos

On 7 Oct 2016, at 4:12, Marc Blanchet wrote:


On 6 Oct 2016, at 15:03, Lee Howard wrote:

Run IPv6+NAT64 as the default IETF SSID. I've discussed with Jari and 
Jim, and they're only reluctant if doing this impedes participants 
getting work done. Does anyone have any ideas for how to show this? 
Volunteers?


I would suggest to have the IETF Chair to take a humm on this during 
the plenary.


Marc.



On this list, I'd like to hear ideas about how to structure 
work/followup on #5 and #6.


Are there other topics we should discuss?

Thanks,

Lee



___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4


___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4


___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

Re: [sunset4] Sunset4 work

[JORDI PALET MARTINEZ]

If we want the customer to be listening ports to accept incoming traffic, then 
IPv6-only access technologies don’t make sense, because that will mean 1 to 1 
IPv4 to IPv6 mapping, right?

In real world, the problem we have is that we are not having sufficient IPv4 
addresses for all the “residential” and cellular networks. Those networks most 
of the time don’t need this mapping, so don’t need the IPv4 address. Even 
corporate networks most of the time (specially SMEs), don’t need to expose 
internal services to outside. So all those cases could survive without a 
“static” 1 to 1 IPv4 mapping, and if app developers know that the path is IPv6, 
new services, IP cameras, VPNs, etc., could work with just native IPv6.

At this way, we can “release” most of the IPv4 addresses that are being used in 
those networks, world-wide, so the ISP that have them, can keep growing using 
pure dual-stack (or another transition that allows 1 to 1 mapping), for those 
customers that really need that.

In that context, yes, both 464XLAT and MAP-T/E, work fine for those customers 
that don’t need the 1-1 mapping, regardless of being a cellular or a wired 
network.

Saludos,
Jordi


-Mensaje original-
De: sunset4 <sunset4-boun...@ietf.org> en nombre de Mark Andrews <ma...@isc.org>
Responder a: <ma...@isc.org>
Fecha: lunes, 17 de octubre de 2016, 21:50
Para: "Heatley, Nick" <nick.heat...@ee.co.uk>
CC: "sunset4@ietf.org" <sunset4@ietf.org>, "jordi.pa...@consulintel.es" 
<jordi.pa...@consulintel.es>
Asunto: Re: [sunset4] Sunset4 work


In message 
<6536e263028723489ccd5b6821d4b2132c3b8...@uk30s005exs06.eead.eeint.co.uk>, 
"Heatley, Nick" writes:
> A thought provoking discussion.
> I don't think the specific transition technology matters so much as the
> "family" it falls into.

Actually the specific transition technology does matter.  It impacts
on what works and what doesn't in the IPv6 connected dual stack
island.

Can the client get a "listening" port to accept externally originating
traffic?  Games need to be able to get listening ports.

Does the transition technology break DNSSEC?

Do the nodes support it especially when the local net is ipv6-only.

Just because the phones went 464xlat doesn't mean that it is the
right fit for the home or office.

Mark

> What matters is whether IETF wishes to showcase IPv6-only down to the
> customer client devices (and then to harvest the expected client issues,
> IPsec failing?), or whether it wishes to showcase "local dualstack on the
> small-stub-network, with an IPv6-only provider connection" to show how
> small-stub-networks could be connected in the future.
>
> Let me explain (longer answer).
> In a number of years' time, as providers run out of IPv4 publics, edge
> "networks" will be brought on with only global IPv6 addressing available
> as the persistent identifier for connected endpoints. (I am assuming in
> Sunset4 we can agree on that).
> But what addressing is within the edge network?
> 1. For large edge networks where private addressing numbers are not
> sufficient to meet the number of connected devices, they will need to go
> IPv6-only, as we have seen with large mobile operators, and learnt with
> Microsoft Enterprise, Facebook etc. These networks all say private IPv4
> addressing is not sufficient.
> 2. For smaller enterprise edge networks then they may well be sitting and
> waiting, or following the above, time will tell.
> 3. For "small-stub-networks" (SSN), where the number of connected devices
> is manageable then clearly IPv4 private addressing is sufficient.  Public
> Wifi access being a perfect example of SSN, or any model using a consumer
> CPE I suppose. So this is the question for sunset4:
> (A) Do we wish to advocate IPv6-only in this SSN scenario? in which case
> all current and future client issues must be resolved (IPv4 literals)
> such that the clients work in the absence of an IPv4 address? This case
> is typified by NAT64/DNS64, other transition mechanisms are available.
> (B) Do we wish to advocate dualstack networking to the client in this SSN
> scenario? Avoid client issues by providing them with a GUA and a IPv4
> private? In which case the transition technology (held within the CPE)
> needs to enable dualstack on the access side but on the provider side,
> cope with only an IPv6-only provider connection. 464xlat in the CPE (like
> 464xlat based tethering from a cellular handset) is an example of a
> transition technology in this family, others are available.
>
> Bot

Re: [sunset4] Sunset4 work

[Mark Andrews]

> progress this issue themselves if they wish IPv6-only to work for them.
> But if (A) is consensus then Sunset4 should start to define the client
> requirements for absence of IPv4 in a SSN. And unlike provider networks,
> enterprise networks own and manage the end to end network use case
> themselves.
>
> The other concern for me about (A) is that I have already oversimplified
> devices as "consumer electronics" as though they only fall into the hands
> of consumers in consumer usecases.
> One of the big issues I foresee with the IPv6-only approach of certain OS
> vendor(s) is that something like a smartphone can be an end device with
> its network interface servicing "on board Apps" (typical mobile
> connectivity), but it can also be a network gateway when used for
> tethering or "internet sharing". The end device (the device tethered on
> the end of the wifi link) may actually be in an enterprise use case ("VPN
> into an office network" for example). By making the SSN IPv6-only we may
> risk placing requirements on the enterprise network (i.e. outside-in
> connectivity like the VPN concentrator, may need certain functionality to
> terminate an IPv6 IPsec VPN etc.). We may need the requirements for (A)
> not just be about end devices but also coordinating requirements for
> various gateways in enterprise networks? If you believe that, it is
> another serious chicken-egg problem; do we need enterprise networks
> upgraded before we can move to a solution for SSNs? (See the IPsec
> comments in https://tools.ietf.org/html/rfc7269#section-6.1 but in the
> general case IPsec VPN is a fail, right?)
>  I am very much in favour of the family of transition technologies that
> enable (B).
>
> SO I inferred a definition of the term SSN to suit my needs in this mail.
> What is really boils down to is that edge networks need some sort of CPE
> or Gateway to the provider network. Do we want that CPE to provide
> dualstack locally or IPv6-only when the provider addresses run out.
> Back to the IETF SSID, what SSN vision do you wish to showcase? (I'd
> prefer a choice for long term rather than "for next meeting" and I'd go
> for something like Jordi's 464xlat in the CPE! Choose wisely :-)
> If an IPv6-only SSID is just to showcase IPsec VPNs still failing, it is
> a bit of a waste of people's time).
> Regards,
> Nick
>
>
>
>
>
> -Original Message-
> From: sunset4 mailto:sunset4-boun...@ietf.org On Behalf Of JORDI PALET
> MARTINEZ
> Sent: 07 October 2016 21:02
> To:
> Subject: Re: sunset4 Sunset4 work
>
> On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ"
> <sunset4-boun...@ietf.org on behalf of jordi.pa...@consulintel.es> wrote:
>
> >This is what Im proposing. May be I miss explained it.
> >
> >NOT asking EVERY device in our network to HAVE 464XLAT client
> (CLAT), but having ONLY our CPE to have it.
> >
> >Nodes will not notice anything.
> >
> >This is what is going to happen in the future in most of the
> networks because they will not have IPv4 for every customer, so why not
> trying it ourselves? Already happening in many cellular networks, like in
> US, which are close to have 60% IPv6 traffic already.
>
> You think 464xlat is what's going to happen in the future in most
> networks?
> Mobile networks, yes, it's a primary transition mechanisms.
> Wi-fi networks operated by ISPs or enterprises are more likely to use
> NAT64, DS-Lite, or MAP, based on what I'm seeing people working on.
>
> I disagree in several points:
> 1) 464XLAT is not only for cellular networks, just read the draft.
> 2) It has been implemented by some CPE vendors. It can be run in Virtual
> Machines as well.
> a. http://www.necat.co.jp/en/ipv6/index.html
> b.
> https://conference.apnic.net/__data/assets/pdf_file/0013/50701/34th_apnic_
> 464xlat.pdf
> 3) Ive tested it in several ISP network. Trials at the time being, but
> coming into production.
> 4) NAT64 is WORST than 464XLAT. NAT64 doesnt sort out the problems for
> apps using literals. 464XLAT sort it out. Yes, NAT64 was developed first,
> but thats the reason 464XLAT was needed, because not everything was
> working in NAT64.
> 5) If you dont trust 464XLAT, then you cant trust in NAT64, because is
> just an incomplete version of 464XLAT.
>
> I agree with you that DS-Lite and MAP are other choices, comparable with
> 464XLAT. They will be a better test, for sure than just NAT64.
>
> If you want something more lightweight than DS-Lite, probably will be
> better to use lw4o6.
>
> Just to make sure it has been understood: Im not asking to implement
> anything

Re: [sunset4] Sunset4 work

[JORDI PALET MARTINEZ]

Nice summary ;-)

Let’s put in this way regarding the IETF SSID and “dogfooding”:

B allows us to *detect* what will fail when we go to A, but not creating the 
users a lot of problems and waste of time, complains to the NOG, etc.

Then, once we have warned those services and apps that fail, exposing publicly 
the results of what is subjected to failure if we go to A, keep using B in our 
network at each following IETF, see the evolution of those “detected failures” 
and may be in one year from one decide if we want to move to A.


Saludos,
Jordi


-Mensaje original-
De: sunset4 <sunset4-boun...@ietf.org> en nombre de "Heatley, Nick" 
<nick.heat...@ee.co.uk>
Responder a: <nick.heat...@ee.co.uk>
Fecha: lunes, 17 de octubre de 2016, 18:04
Para: "jordi.pa...@consulintel.es" <jordi.pa...@consulintel.es>, 
"sunset4@ietf.org" <sunset4@ietf.org>
Asunto: Re: [sunset4] Sunset4 work

A thought provoking discussion.
I don't think the specific transition technology matters so much as the 
"family" it falls into. 
What matters is whether IETF wishes to showcase IPv6-only down to the 
customer client devices (and then to harvest the expected client issues, IPsec 
failing?), or whether it wishes to showcase "local dualstack on the 
small-stub-network, with an IPv6-only provider connection" to show how 
small-stub-networks could be connected in the future.

Let me explain (longer answer).
In a number of years' time, as providers run out of IPv4 publics, edge 
"networks" will be brought on with only global IPv6 addressing available as the 
persistent identifier for connected endpoints. (I am assuming in Sunset4 we can 
agree on that).
But what addressing is within the edge network?
1. For large edge networks where private addressing numbers are not 
sufficient to meet the number of connected devices, they will need to go 
IPv6-only, as we have seen with large mobile operators, and learnt with 
Microsoft Enterprise, Facebook etc. These networks all say private IPv4 
addressing is not sufficient.
2. For smaller enterprise edge networks then they may well be sitting and 
waiting, or following the above, time will tell.
3. For "small-stub-networks" (SSN), where the number of connected devices 
is manageable then clearly IPv4 private addressing is sufficient.  Public Wifi 
access being a perfect example of SSN, or any model using a consumer CPE I 
suppose. So this is the question for sunset4:
(A) Do we wish to advocate IPv6-only in this SSN scenario? in which case 
all current and future client issues must be resolved (IPv4 literals) such that 
the clients work in the absence of an IPv4 address? This case is typified by 
NAT64/DNS64, other transition mechanisms are available.
(B) Do we wish to advocate dualstack networking to the client in this SSN 
scenario? Avoid client issues by providing them with a GUA and a IPv4 private? 
In which case the transition technology (held within the CPE) needs to enable 
dualstack on the access side but on the provider side, cope with only an 
IPv6-only provider connection. 464xlat in the CPE (like 464xlat based tethering 
from a cellular handset) is an example of a transition technology in this 
family, others are available.

Both of these SSN approaches assume that within the core of the internet 
their remains the legacy IPv4-only content, which seems valid for "consumer 
electronics networking" in general.
They differ on how we expect consumer electronics networking to evolve (or 
how we *want* it to evolve). We could advocate both for sure, but not sure if 
that helps move sunset4 forward!

My opinion, take it or leave it, is that pragmatically, a SSN vision based 
on (B) is less problematic. It is less dependent on moving a whole collection 
of Consumer Electronics away from today's deficient state, because (A) 
essential demands they work in absence of IPv4. This requires concerted effort 
to remove the "IPv6-only" mode bugs that we know exist.
The biggest problem with (A) is that you cannot make the network model the 
compulsory model, until the majority of Consumer Electronics is fully ready, 
which creates another network provider chicken-egg problem. You can do OS by OS 
(something that a popular smartphone and PC vendor is attempting with 
IPv6-only, NAT64) but network providers don't wish to create individual network 
paradigms for each OS.

Then we look back at 2., above. Enterprises moving to IPv6-only - do we 
have some need and obligation within Sunset4 to push (A) to avoid Enterprises 
being trapped in an IPv4 world? To leave dualstack in one part of the edge 
(SSN) - does it undermine the benefits we are telling enterprises on IPv6-only 
e.g. removal of dual address complexity. Personally I believe this is only 
really an issue in practice where the enterprise is so

Re: [sunset4] Sunset4 work

[Mark Andrews]

I would do this for all the mechanisms we have designed to provide
IPv4 over IPv6 with a new one each meeting (I would suggest switching
each day of the meeting but I suspect Jim would kill me).

e.g. DS-LITE, MAP-*

For DS-LITE I would even suggest that we do DS-LITE host mode at
the end.

Mark

In message <8c661edc-4d87-4cb6-9c42-24bf5b0dd...@lists.zabbadoz.net>, "Bjoern A
. Zeeb" writes:
> On 6 Oct 2016, at 21:16, JORDI PALET MARTINEZ wrote:
>
> >
> > On 10/6/16, 3:30 PM, "sunset4 on behalf of JORDI PALET MARTINEZ"
> > 
> > wrote:
> >
> > >Despite how much I like all those ideas, I don't think we are
> > ready to have an IPv6-only IETF network.
> > >
> > >Unfortunately, there are many applications, VPNs, etc., which
> > will not work just with NAT64, because literals, etc.
> >
> > Can you make a list?
> > Or, can we start a list, and have people add things to it at the
> > next meeting, so we can work to resolve them by the following meeting?
> >
> > The idea is not to create a list, on the other way around, is to use
> > our behaviour to discover what are the apps or destinations that
> > we use and dont support IPv6, to create the list
> > automatically.
> >
> > We just need some kind of logging of everything using the DNS64 or the
> > CLAT, which means is not IPv6 enabled.
>
> Nastygram.  So make the default IETF SSIDs IPv6-only or (+NAT64) if you
> want.  Then have the ietf-legacy network, which would give you IPv4 and
> a portal page penalty that you have to state the nature why you
> have to use this network and cant live on the default one.   Id be
> so curious to see what happens when people finally have to start
> thinking about it.. and open internal tickets ..  It was great fun doing
> it 6-ish years ago, ..
>
> /bz
>
> ___
> sunset4 mailing list
> sunset4@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

Re: [sunset4] Sunset4 work

[Marc Blanchet]

On 6 Oct 2016, at 16:22, Lee Howard wrote:



On 10/6/16, 3:30 PM, "sunset4 on behalf of JORDI PALET MARTINEZ" 
 
wrote:


Despite how much I like all those ideas, I don't think we are ready 
to have an IPv6-only IETF network.


Unfortunately, there are many applications, VPNs, etc., which will 
not work just with NAT64, because literals, etc.


Can you make a list?


I created a link to create a page on the wg trac: 
https://tools.ietf.org/wg/sunset4/trac/wiki.  Click on the link and it 
will create a new wiki page so people can put data. You need to login in 
before with your ietf credentials.


However, (speaking as individual), I’m not sure we want to start that 
endeavour. Others have tried in the past and it is more complicated than 
it appears.


marc.

Or, can we start a list, and have people add things to it at the next 
meeting, so we can work to resolve them by the following meeting?






I will suggest something alternative at this stage:

Having the IETF network as a typical SME or residential customer of 
an ISP which has run out of IPv4 addresses, provides an IPv6-only WAN 
link and uses CLAT (464XLAT) at the customer CPE.


How well-tested is that in laptop environments? The only deployments I 
know of are on mobile networks, which have a different set of 
applications and protocols using them. Do you know of others?




This means having GUA addresses but only private IPv4 address, and 
having a router behaving as the IETF network “CPE” supporting 
CLAT.


Of course we still need the NAT64+DNS64.

This way, we will have a high proportion of IPv6 traffic and we can 
take some measurements about “what” apps and Internet end-points 
are still using the NAT64/DNS64, and what apps are using the CLAT and 
we can also have the secretariat or ISOC to make sure to talk with 
those organizations to let know them that they have a problem …


Do you mean NAT64 on a different SSID as the 464xlat? I'm confused.

Lee




Saludos,
Jordi


-Mensaje original-
De: sunset4  en nombre de Lee Howard 


Responder a: 
Fecha: jueves, 6 de octubre de 2016, 21:03
Para: 
Asunto: [sunset4] Sunset4 work

   After the last WG meeting, I walked away with seven things that I 
thought we needed to do:



   1. Update my v4historic draft. I intend to do this in time for the 
Seoul meeting.
   2. Phillip Hallam-Baker suggested something like 
"draft-baker-ipv4status-its-complicated." I would like to hear more 
about this, and read a draft.
   3. The IAB should tell partner SDOs that their work should support 
IPv6. We're working on this, and should have an update before the 
meeting.
   4. The IESG or IETF community should squelch IPv4-only charters. I 
think the IESG would rather see a community statement, so we're 
hoping for a draft in the next couple of weeks.
   5. WG Chairs and IETF communicty looks for IPv4 literals, 
IPv4-only examples, IPv4 dependencies, and clean them up. Does anyone 
see a way to structure this, or is there no followup to be had here?
   6. Run IPv6+NAT64 as the default IETF SSID. I've discussed with 
Jari and Jim, and they're only reluctant if doing this impedes 
participants getting work done. Does anyone have any ideas for how to 
show this? Volunteers?

   7. Update id-nits checked to look for IPv4-only examples. Done!

   I therefore think there's enough work to justify a meeting in 
Seoul, and have said so to the WG chairs.


   On this list, I'd like to hear ideas about how to structure 
work/followup on #5 and #6.


   Are there other topics we should discuss?

   Thanks,

   Lee



   ___
   sunset4 mailing list
   sunset4@ietf.org
   https://www.ietf.org/mailman/listinfo/sunset4




**
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 use of the 
individual(s) named above. If you are not the intended recipient be 
aware that any disclosure, copying, distribution or use of the 
contents of this information, including attached files, is 
prohibited.




___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4


___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4


___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

Re: [sunset4] Sunset4 work

[Lee Howard]

On 10/6/16, 3:30 PM, "sunset4 on behalf of JORDI PALET MARTINEZ" 
 wrote:

>Despite how much I like all those ideas, I don't think we are ready to have an 
>IPv6-only IETF network.
>
>Unfortunately, there are many applications, VPNs, etc., which will not work 
>just with NAT64, because literals, etc.

Can you make a list?
Or, can we start a list, and have people add things to it at the next meeting, 
so we can work to resolve them by the following meeting?


>
>I will suggest something alternative at this stage:
>
>Having the IETF network as a typical SME or residential customer of an ISP 
>which has run out of IPv4 addresses, provides an IPv6-only WAN link and uses 
>CLAT (464XLAT) at the customer CPE.

How well-tested is that in laptop environments? The only deployments I know of 
are on mobile networks, which have a different set of applications and 
protocols using them. Do you know of others?

>
>This means having GUA addresses but only private IPv4 address, and having a 
>router behaving as the IETF network “CPE” supporting CLAT.
>
>Of course we still need the NAT64+DNS64.
>
>This way, we will have a high proportion of IPv6 traffic and we can take some 
>measurements about “what” apps and Internet end-points are still using the 
>NAT64/DNS64, and what apps are using the CLAT and we can also have the 
>secretariat or ISOC to make sure to talk with those organizations to let know 
>them that they have a problem …

Do you mean NAT64 on a different SSID as the 464xlat? I'm confused.

Lee

>
>
>Saludos,
>Jordi
>
>
>-Mensaje original-
>De: sunset4  en nombre de Lee Howard 
>
>Responder a: 
>Fecha: jueves, 6 de octubre de 2016, 21:03
>Para: 
>Asunto: [sunset4] Sunset4 work
>
>After the last WG meeting, I walked away with seven things that I thought 
> we needed to do:
>
>
>1. Update my v4historic draft. I intend to do this in time for the Seoul 
> meeting.
>2. Phillip Hallam-Baker suggested something like 
> "draft-baker-ipv4status-its-complicated." I would like to hear more about 
> this, and read a draft.
>3. The IAB should tell partner SDOs that their work should support IPv6. 
> We're working on this, and should have an update before the meeting.
>4. The IESG or IETF community should squelch IPv4-only charters. I think 
> the IESG would rather see a community statement, so we're hoping for a draft 
> in the next couple of weeks.
>5. WG Chairs and IETF communicty looks for IPv4 literals, IPv4-only 
> examples, IPv4 dependencies, and clean them up. Does anyone see a way to 
> structure this, or is there no followup to be had here?
>6. Run IPv6+NAT64 as the default IETF SSID. I've discussed with Jari and 
> Jim, and they're only reluctant if doing this impedes participants getting 
> work done. Does anyone have any ideas for how to show this? Volunteers?
>7. Update id-nits checked to look for IPv4-only examples. Done!
>
>I therefore think there's enough work to justify a meeting in Seoul, and 
> have said so to the WG chairs. 
>
>On this list, I'd like to hear ideas about how to structure work/followup 
> on #5 and #6. 
>
>Are there other topics we should discuss?
>
>Thanks,
>
>Lee
>
>
>
>___
>sunset4 mailing list
>sunset4@ietf.org
>https://www.ietf.org/mailman/listinfo/sunset4
>
>
>
>
>**
>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 use of the 
>individual(s) named above. If you are not the intended recipient be aware that 
>any disclosure, copying, distribution or use of the contents of this 
>information, including attached files, is prohibited.
>
>
>
>___
>sunset4 mailing list
>sunset4@ietf.org
>https://www.ietf.org/mailman/listinfo/sunset4

___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

Re: [sunset4] Sunset4 work

[JORDI PALET MARTINEZ]

Despite how much I like all those ideas, I don't think we are ready to have an 
IPv6-only IETF network.

Unfortunately, there are many applications, VPNs, etc., which will not work 
just with NAT64, because literals, etc.

I will suggest something alternative at this stage:

Having the IETF network as a typical SME or residential customer of an ISP 
which has run out of IPv4 addresses, provides an IPv6-only WAN link and uses 
CLAT (464XLAT) at the customer CPE.

This means having GUA addresses but only private IPv4 address, and having a 
router behaving as the IETF network “CPE” supporting CLAT.

Of course we still need the NAT64+DNS64.

This way, we will have a high proportion of IPv6 traffic and we can take some 
measurements about “what” apps and Internet end-points are still using the 
NAT64/DNS64, and what apps are using the CLAT and we can also have the 
secretariat or ISOC to make sure to talk with those organizations to let know 
them that they have a problem …


Saludos,
Jordi


-Mensaje original-
De: sunset4  en nombre de Lee Howard 
Responder a: 
Fecha: jueves, 6 de octubre de 2016, 21:03
Para: 
Asunto: [sunset4] Sunset4 work

After the last WG meeting, I walked away with seven things that I thought 
we needed to do:


1. Update my v4historic draft. I intend to do this in time for the Seoul 
meeting.
2. Phillip Hallam-Baker suggested something like 
"draft-baker-ipv4status-its-complicated." I would like to hear more about this, 
and read a draft.
3. The IAB should tell partner SDOs that their work should support IPv6. 
We're working on this, and should have an update before the meeting.
4. The IESG or IETF community should squelch IPv4-only charters. I think 
the IESG would rather see a community statement, so we're hoping for a draft in 
the next couple of weeks.
5. WG Chairs and IETF communicty looks for IPv4 literals, IPv4-only 
examples, IPv4 dependencies, and clean them up. Does anyone see a way to 
structure this, or is there no followup to be had here?
6. Run IPv6+NAT64 as the default IETF SSID. I've discussed with Jari and 
Jim, and they're only reluctant if doing this impedes participants getting work 
done. Does anyone have any ideas for how to show this? Volunteers?
7. Update id-nits checked to look for IPv4-only examples. Done!

I therefore think there's enough work to justify a meeting in Seoul, and 
have said so to the WG chairs. 

On this list, I'd like to hear ideas about how to structure work/followup 
on #5 and #6. 

Are there other topics we should discuss?

Thanks,

Lee



___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4




**
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 use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.



___
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4