Beijing,2011 September 26-27




   Notetakers: Ole Troan, Ralph Droms, Wojciech Dec



0900 - Introduction section


  Alain going through introduction slides.

  Agenda bashing:

    Alain re agenda: random order is for fairness.

    Woj: It would make sense to have operator input first.

    Ole: Two ways of doing it. Either apply logical structure first or deep dive first.

    Ralph: Fine with the order

    Jari: Come here to do divide & conquer. But the deep dive may give some learning. Analytical part.

           Agree, with Wojciech and Ole.


   Hui: Do we have the motivation draft today?

     Alain: No.



    ID card(presented to assess each solution):

    - NAT bindings maintained on CPE, not CGN

    - H&S vs Mesh

    - Implicit or explicit provisioning

    - Address mapping rules

    - Integration with existing mechanism


  Xing: Are they orthogonal. We need to define some orthogonal axis.

  Alain: Yes, we need that.

  Woj: What do you mean by integration with existing mechanism

  Alain: Characteristic. How it relates to things that already exist.

  Woj: Two comments. The plugs are there for a reason. The solution was the multiprotocol solution.

       You mentioned NAT was outside of scope. You declaring some element out of it?

  Alain: No, we don't exclude dIVI, but we don't want details on NAT64 or NAT46. or NAT444.

  Jari: Talk about general aspects. I'm worried about if we are doing one or multiple standards. It would be far easier if we came up with one answer rather than multiple answers. It isn't about filling all the space in the solution matrix.

        This is not just a technical discussion, we have to bridge it to the ISP requirements. So from my perspective it should be backed in wide interest in SP interest in that space.

  Ralph: Agree with Jari, one solution is easier to move forward with compared to multiple solutions. We have an opportunity to avoid that.

Hope everyone will focus on understanding the common requirements. We are doing this to meet operator requirements. We need to minimize the number of solutions.

  Woj: Fully agree. Quantifying the operator interest. One can always speculate what operators want...

  Xing: Agree

  Ralph: To Woj. We have people in the room that we can take a que from. And the working group. But there are other interests. First hand accurate input.

  Jari: A few other things. What do we need to get the end? An RFC or set of RFCs on this technology.

         Motivation document needs some more work.

         Have to make selection / decisions on big topics. On Alains slides. Tunnel versus translate. Or address mapping rules

         There are other things too. I'm concerned to when dividing ports to customers, it creates some inflexibility.

         Changing the allocation will be difficult. That should be looked at. Consequence of port allocation.

  Ralph: As we go through the discussion, keep in mind that parts can be kept separate. e.g. mapping can be kept separate and independent of "transport".



2. Deep Dive (7hours) - Chairs and presenters


  Some discussion on the "deep dive" agenda.

  Alain, Woj, Hui, Yong



9:30-10:30 Xiaohong Deng

1. Architectural considerations of Stateless A+P with a focus on SMAP


  Woj: ICXF: Are you showing that as a translator?

  Xiao: Yes, something like that. It is doing encapsulating. PRD: encapsulating

  Linjian: Q: What happens during with the packet goes through the CGN. What changes after the CGN? What happens with the IPv6 packet?

  Xiao: Stateless address mapping. If it goes to the outside internet (ICXF) or inside packet.

  Alain: Send presentations!

  Xing: Static port range with PRR, dynamic tunneling

  Jari: IPv6 routing doesn't take port space into account.

  Xiao: CPE is going to have the same IPv6 prefix for stateful and stateless traffic.

  Jari: I'm being slow this morning... My issue is that when the port range change, then the IPv6 address change?

  Xiao: It is impossible to not make the IPV6 prefix length dependent on.

  Satoru: Assigning the IPv6 prefix. To avoid allocating the well known IPv4 address? Mapping rule encoding

          Full IPV4 address IPv6 operator has to avoid allocating IPv6 prefix that results in well known IPv4 address?

  Alain: The IPv6 address of the customer is not related to the IPv4 address?

  Remi: Independent of IPv6 and IPv4. Includes the full IPv4 address in the IPv6 address.

  Woj: Still struggling. DHCPv6 options.  

  Ole: Independent or dependent?? Explicit provisioning.

  Roberta: Clarification about the prefix. Either well known prefix, or a prefix from the service provider. Either way.

  Remi: Share understanding. The port range is learnt from the IPv6 prefix. It has a prefix that includes an IPv4 address and a port mask.

  Ralph: If there is an algorithmic mapping, there is no need to have the IPv4 address in the DHCP option.

  Alain: there are two different things. one is the source address and one is the destination address.

         my understanding was that they use DHCP to give the address and port range, but to find the IPv6 destination the algorithmic mapping.

Ole: Question on how IXF-IXF traffic is meant to happen

Xiao: Rules need to be applied on IXF.


2. DHCPv6 Options for Shared IP Addresses Solutions


  Alain: Carrying IPv4 addresses in IPv6 options?

  Ralph: I don't think the DHC WH has a formal opinion. The case of optimizing DHCP to carry both addresses in one protocol in the DS case, they have stayed away from

  Alain: 3 options. Carry DHCPv4 over IPv6, DHCPv4 payload, or DHCPv6.

  Alain: If the packets go through the tunnel. It is an easier way to configure DHCP???

  Ole: But you don't have IPv4 transport.



10:45-11:15 Peng Wu

DHCPv4 over IPv6




Presents address/port delegation method for stateful solutions(public 4over6).

DHCP tunnel vs. adaptation: apparent problems with dhcpv4 over softwire tunnel highlighted by DHC WG - DHC would like it to be more generic, applicable to any tunnel.


  Jari: Why option 82, isn't the IPv6 the soruce address in the packet?

  Peng: Not available for DHCP server process. It is possible, but it is extra effort.

  Remi: Is there a security issue here? The packet has the real IPv6 address; if they are different from the option 82.

            Is that an issue?

  Peng: Not directly related to DHCP

  Jari: There is, but how serious is it.

  Alain: Here we have two ways of doing it. From Ralph what is the more generic.

  Ralph: I don't follow why tunnel or transport one is more generic or one is more specific?

         There are some details in the tunnel solution. the biggest issue that dhcpv4 assumes that broadcast is available.

   Alain: if it is a p2p tunnel, then broadcast is simple.

   Ralph: if you are saying that there is a mechanism for... I'm not sure that the broadcast semantics map into the IPv6 transport.

   Ole: Need DHCP server discovery and new DHCPv4 options for 4rd. This only applies to the DS-lite case.

   Remi: Same point.

   Peng: Agree.

   Woj: Basic question. Intent of this proposal, recreate a link-layer over IPv6. We just pass DHCPv4 over tunnel.

   Alain: different properties

   Woj: If we talk about port range, then why not just define a new DHCPv4 option, just do it on IPv4.

          What are the requirements for this?

   Alain: Will be covered later.



11:15-12:15 Naoki Matsuhira

Motivation for developing SA46T and SA46T-AS

SA46T & SA46T-AS technology dive


ISATAP for IPv6. Map full IPv4 address into IPv6.


  Ole: Questions on:

        - import IPV4 routing into IPv6

        - host to host

        - separate IPv6 native network

        - provisioning

         - what happens with local applications?

  Xing: Address mapping rule. It is different from local or Internet?

  Alain: Related to H&S or mesh?

  Xing: E.g. in translation case, there is IPv4 translatable there is IPv4 converted address. Should use the same prefix, but not necessary.

  Alain: Adds row in ID card matrix to identify different mapping rules.


--------------- 12:15-13:30 Lunch ---------------


13:30-14:00 Tetsuya Murakami

IPv4 Residual Deployment on IPv6 infrastructure - protocol specification


  4rd specification


  Jari, Alain: How does ICMP work?

  Alain: How does IPsec work?

  Jari: IPsec works with IPsec NAT traversal in UDP encap.

  Alain: Fragmentation?

  Remi: Consequence of address sharing

  Alain: A+P issues needs to be clearly documented somewhere.


  Remi: The first document of 4rd was -sam.

  Alain: Thanks.



14:00-14:30 Remi Despres

Stateless Address Mapping for IPv4 Residual Deployment (4rd)


4rd b1/b2

Decoupled from encap or translation. Allows both.

4rd a,b, b1, b2 - changes to algorithm and mapping

Well known OUI based IID for mapped address representation


  Jari: I wanted more IPv6 space, but we can't do that unless we also give IPv4 prefix.

  Remi: yes, implicitly.

  Jari: they have different class of service, the part I'm not fine with.

If you bind IPv6 allocation size to the IPv4 allocation size... I'm not happy with that.

  Remi: That's implied by stateless solution.

  Alain: Go to feeling of the table.



14:30-15:30 Wojciech Dec

1. Stateless 4Via6 Address Sharing

  Comparison of encap and translate solutions. Majority of details are the same. Differences lie in the context of usage. Tunneing forces changes of architecture or constrains deployment options, eg location of functions.


Alain: MPLS is tunneling.

Woj: Different context; MPLS not used to the CPE (esp in residential).

Remi: How is DF bit handled in translation?

Xing: As per rfc NAT64. Either copied and IPv6 extension header used, or MTU too big ICMP message sent back. No information loss.

  Woj: IPv4 functions done where IPv6 subscriber state is. i.e. on BNG.

  Long discussion on the need for features, in the network. How translation affects that. Consequence of fragment bit on translation.


2. Stateless port mapping algorithms overview



15:45-16:15 Qiong Sun

Lightweight 4over6

Stateless 4over6


  Sun: 94% of traffic to BR, 6% CE to CE.

  Remi: Questions of the rules. Does it need a table for which customer has which multiplexing ratio?

  Sun: Not per subscriber but fixed per IPv4 prefix.


  Alain: The rules are the same as in divi-pd?

  C: The suffix isn't used in tunnel mode. OTherwise same as divi-pd.

  Remi: Can it work with shorter than /64

  Xing: In practice not.

  Remi: In the PD version, is there a separate prefix for translation and one for native?

  Xing: /64

  Ole: So /56 is OK

  Woj: yes.


  Ole: Purpose of the suffix bits?

  Xing: From dIVI


  Satoru: what if port id is exceeding the address sharing ratio?



  Jari, Woj: Discussion about features / classification of the translated traffic.

  Ralph, Remi: DHCPv6 discussion



16:15-17:15 Xing Li

1. dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation

Presented old modulo algorithm + new algorithm

dIVI PD is by default hub & spoke. Uses different prefix in the upstream than in the downstream. Can be optimised for mesh. Allows use of /64 or shorter.

DIVI is by default mesh - requires stateful DHCP assignement (extra subnet)


  Remi, Xiao: questions on the example of port mapping

  Alain: Why is stateful translation bad?

  Xing: You need to maintain ALGs. you cannot recover original IPv4 address when mapping back.

        How can you sync ALG on both sides of the translation


2. dIVI: Dual-Stateless IPv4/IPv6 Translation



17:30-21:00 Socail Event (depart at FIT West Lobby at 17:30)



--------------- Tuesday 8:30-17:30 ---------------



8:30-9:00 CERNET Operation Center tour (FIT 1-101, TSINGHUA UNIVERSITY)





9:00-10:00 Gang Chen

1. 4via6 Stateless Translation


  Ole, then Alain: Comparison of MAP algorithms scheduled for this afternoon.

  Unified address mapping function discussion stopped by chair, until this afternoon.


2. Prefix Delegation in 4V6   Tao Sun


  Remi: Why is multiple shared IPv4 addresses needed?

  Remi: You could extend the port set

  Tao: To give more port space multiple shared IPv4 addresses.

  Discussion on the meaning of "address set".

  Remi gets verification that for each address in the set, the port range is the same.

  Xing: Comments on the interface identifier "v4 prefix". It should be subnet.

  Continuing discussion on address sets. Ole, Remi, Jari.

  Alain: In Quebec we had discussion on signalling or doing it simple. We want more flexibilty.

  Xing: This is a new format. If same as 4rd you don't need to describe it, if it is new you must.

  Jari, Alain, continue discussion on address set.



10:00-10:30 Xiaohong Deng

DS-Lite AFTR NAT Bypass: Co-located B4 and NAT Model


  Alain: you don't need DHCP, you can do port reservations only with PCP. Even 200.

  Remi: Randomization within the portset?

  Xiao: If you have continuous port set, you can randomize.

  Alain: If you just do PCP requests you will get random allocation.


  Terminology discussion on stateful/stateless

  Jari: On the note of state. there is per-flow state (e.g. TCP flows) and there is per subscriber state. that can either be dynamic or static.

  Ralph: and it matters how much state there is from a scalability perspective.

  Remi: And there are solutions that don't have per subscriber state.


  Peng: Lightweight 4over6 draft basically describes the same mechanism


For incremental random port range assignement, ds-lite with pcp appears best option.



10:30-10:45 Coffee break



3.Invited talks: Operator's perspective




10:45-11:15 Satoru Matsushima

An operator's view, address mapping in particular with our cases


  Alain: why the case for special IPv4 addresses in the embedded prefixes. 0/8 127/8 and so on

  Remi: if the provider allocates prefixes that belongs to the space allocated to this provider. all the special addresses will be taken care of. algorithm doesn't have to know.

  Satoru: Chained CPE discussion. Separate IPv6 CPE and 4rd CE

  Maoke: In this scenario is the IPv4 NOC and the IPv6 NOC are they different?

  Satoru: Could be same, but different policy.

  Maoke: 4rd BR and 4rd CE are they then in the same operator?



11:15-11:35 CERNET - Xing Li

The operational requiements and the experience of the single and dual

stateless translation concerning CERNET (IPv4) and CNGI-CERNET2 (IPv6).


  Running 40G of IPv6 (translated) traffic today. 20% of overall.

Planning cernet-ng for regional schools. Required to be IPv6 based with stateless translators. Schools to be v4&v6

Divi casues no harm:

Collected statistical data shows that fragemnts are less that 0.01% negligible IP option use seen - some of it apparently bogus

Useful part of ICMPv4 translatable to ICMPv6

Requires operational tools to be IPv6 based not tunnel based.

Showed that this is possible today with existing IPv6 routers. Not possible with tunneling.


  Xing: CERNET2 design principle, as complex as possible.

  Cernet2 IPv6 is about 20% of IPv4 traffic.

  Jari: For the fragmented packet you need to keep state on the translators?

  Xing: Yes, for 0.1% of the packets you need to keep state.

  Maoke: I'll add some information on the UDP part. UDP fragmented is 99% is p2p software.

  Remi: IF there is an IPv4 packet too large for the translation, it will be fragmented.


  Remi: Please keep somewhere. as an informational

  Woj: The original draft on v4v6 draft. was supposed to document some of these issues.



11:35-11:55 China Mobile - Hui Deng


IP fragmentation seen in the network as an issue

Running services running multiple IPv4 features. Have commits from vendors for same features on IPv6. No such features or commits for IPinIP, and not available.

Operationally simpler to run v4-v6 translated solution, thus not interested in tunneling.

Smart-pipe architecture; multiple network elements.

Intention for smart pipe is to keep the same network architecture on ipv6, rather than change it around tunnels

Encapsulation solution also shown to require complex upgrades to control (management) plane of the network.



11:55-12:15 ChinaTelecom – Chongfeng Xie


Largest wireline bradband network. 70M subs

Remaining IPv4 address space is scattered (less that /23)

Needs: Incremental deployment, rather than complete upgrade.

Only 6% of traffic goes CPE-CPE. Rest through IP aggregation. No split on local/vs non-local traffic.




--------------- 12:15-13:30 Lunch ---------------






13:30-14:00 Linjian Song

Head compression



4.Divide& conquer (2 hours)




14:00-14:30 Ole Troan

Port mapping rules

  Table of must's and nice to have characteristics for port indexing/mapping algorithm & methods



15:00-15:30 Rémi Després

Port mapping rules



Map technologies into problem space

Goal: analyze overlaps & differences



15:30-16:00 Ole Troan

Comparision between encapsulation and translation



16:00-16:30 Coffee break



5. Path forward (1 hour)



Goal: evolution of technologies, integration with existing mechanism, gap


Goal: winnow down list of candidates




Alain: Taking stock.  Going through B1, B2, B3.

Ralph: Dynamic state

A: covered in B1, B2


Wojciech making the point that there should be agreement.

Jari: stating that the ease of doing IPV6 features doesn't reflect the current world.

Followed up by Kevin that agreement that feature processing is easier in translation case.

Remi: if we start from divi-pd, 4rd and 4rd-b2 then we are on the same page.

      describes a comprimise solution for mapping algorithm to accommodate translation requirements, to get IPv4 address + PSID into the IPV6 IID. if we have that, you can do the ACL...


Alain: rephrase. if you take this as a requirement, you can achieve this in an encapsulation solution?

Woj: No, you are referring to the suffix part. but that does not address the 5 tuple.

Ralph: Stating the observation that there is a set of operators thinking that doing features in a translation solution is easier, some that doing it in encapsulation solution.


Ralph: The translation is more unknown than encapsulation. e.g. what happens if a translated packet is received by an IPv6 application expecting IPv6 addresses in the payload.


Alain: Way forward.

Form a design team for proposed unified address & port mapping algorithm PS document.

Also do a DHCPv6 option to provision the mapping algorithm.


Way forward part 2

Translation versus encapsulation


what's the consequence of CPEs. interoperability?

what do we publish as RFCs?

(Slides)Several options regarding IETF recommendation & document track


Ralph: Commenting on way forward. encourage everyone to think of all the external parties, SDOs, rest of softwires, CPE vendors, implementors. and finally as a nit, the options lists aren't mutually exclusive.


Jari: with my AD hat on, it is important to check this with the mailing list, and with the IESG, since they sometimes say no.

      my personal opinion is that interoperability is important, because of this CPE issue. can I go to bestbuy and expect that it does what I need.

also influencing the cost of running your network. my preference is the option, based on maturity I would pick option 1.


Ralph: to follow up on cpe interoperability. in case of DHCPv6 and PD we're finding that we have to go back and modify the PD specification because of broken implementations.

while you cannot avoid broken implementations, then make it simple for them


Jari: (personal) tunnel standard, translate informational

Woj: there is an option missing. the do nothing option.

the strength of the IETF is to formulate specifications without specifying how operators should run their network. arguing for option 7: do nothing.

Personal opinion 5 - netural applicability statement is best; explain tradeoffs and let industry and vendors choose.

Difference between standards and informational only matters to the IETF


Jari: clarification. leave the decision for what the standard for later.

Woj: standards or informational is lost on the outside; option 5 or 7.


Alain: both can be published as experimental.

Woj: if the goal is to influence outside, then it doesn't matter what the status is. experimental isn't the right track.

Ole - difference between the two is minimal.


Remi: option 5 is it something that tells everything. is it combinable with technical description.

Alain: not mutually exclusive. we need to document both an encapsulation story and a translation story. how do we do it?

       and how do we communicate some preference if we do? through a standards level or an applicability document?


Remi: it would be easier to make decision after having the description.

the second point, this unified address format we hope to get, modifies the mechanisms, making them much more similar.


Jari: holding the decision is possible. it would be expecting that the working group would like to know.. working on something for a long time, it would good to know the end goal, but that is not something we need to continue discussing.


Ralph: we do understand quite a bit of what the analysis document will say, it doesn't hurt what we know today, leaving as an internet drafts while working on the technical descriptions.


Woj: yes, we can publish the table from Ole's presentation.


Alain: opinion from CPE vendors


Jacni: In an early stage I do care since we do it in software. we prefer reuse of current code given the encapsulation solution like DS-lite later we get hardware to do it, then I don't care if it is encapsulation or translation.


Alain: asks about impact to CPE to operators.


Roberta: from the BBF we had this discussion many times. DSlite versus 6rd discussion. BBF has modules, one for 6rd one for DS-lite and so on.

         TI as operator chooses what is needed and vendors build it


China Telecom: it is difficult for us to make decision, we want IETF to make clear recommendation. more guidance.

China mobile: impact on CPE.  I talk with CPE vendor, we need both, depends on scenario.

Softbank: Managed CPE, we already have encapsluation. Separated use case. wireline in encapsulation, translation for wireless. Complexity not an issue

Orange: no control of CPE. we always provide CPE. to different orange countries.

Xing: multimode is not a problem for CPE.


Ole: Explaining about RFC6204 CE requirements

Remi: if we have a unified mapping algorithm,... having both translation and encapsulation lose...

Woj: it doesn't matter to the CPE, ultimately people do one, two or none. the retail will be steared by its own forces.

     if I go to bestbuy ... it comes down to what we do with those options

     we already heard there is modularisation, the retail market compliance against both...

Woj - why the question? It's always extra code; someone may want 6rd and ds-lite, others not - that's also complexity. Influencing the retail market through RFCs is a non-goal. Plugging a v6-only CPE to a ds-lite-only network will not work either, even if ds-lite rfc is there.


Ole - modular specs being progressed through v6ops and to other bodies, we already have v6 module, 6rd, ds-lite. This would be another modular extension. Certification with IPv6-ready logo.


Jari: size matters. with one solution it makes it easier. more vendors, more operators. it is not all about code.

Kevin: if we can reach one approach then it is easier.


Tetsuya: I implemented translation and encapsulation. want it into a single module. address mapping as a PS.



Jari: Outcome of meeting, agreement to publish two RFCs(as per slide1) for both translation and encapsulation. Discussion on what is to be the IETF recommendation, if any, will continue in the WG.