Discussion on Host-based IPv6 Translation denghui@chinamobile.com - - PowerPoint PPT Presentation

discussion on host based ipv6 translation
SMART_READER_LITE
LIVE PREVIEW

Discussion on Host-based IPv6 Translation denghui@chinamobile.com - - PowerPoint PPT Presentation

Discussion on Host-based IPv6 Translation denghui@chinamobile.com Outline Conventional IPv4 application support Network scenarios Why we need host based translation Vs DS Lite, NAT64, Double NAT Signaling procedure of


slide-1
SLIDE 1

Discussion on Host-based IPv6 Translation

denghui@chinamobile.com

slide-2
SLIDE 2

Outline

  • Conventional IPv4 application support
  • Network scenarios
  • Why we need host based translation
  • Vs DS Lite, NAT64, Double NAT
  • Signaling procedure of PNAT44COM
  • What to do next?
slide-3
SLIDE 3

Plenty of IPv4 legacy on the host side (By Teemu)

I. Applications

– IPv6 has not generally been a real requirement for applications – Many applications are IPv4-only, percentage unknown – Many legacy applications will never see update to IPv6

II. Runtime environments

– All runtime environments do not support IPv4, while most should – A common runtime environment in mobile environment is Java Platform, Micro Edition (Java ME). It has Mobile Information Device Profile, of which newest version 2.0 (MIDP 2.0) that is IPv4-only. IPv6 support is coming with MIDP 3, but it is not yet standardized

III. External devices

– A host may implement internet connection sharing for other hosts – These hosts are not necessarily IPv6 capable at all, or may run IPv4-only applications, or IPv4-only runtimes..

slide-4
SLIDE 4

The host side… (by Teemu)

  • will feel strong incentive to support IPv6 only after networks

start actually providing IPv6 connectivity

  • Should not be forced to upgrade everything due IPv6

deployment

  • will have a long IPv4 tail
slide-5
SLIDE 5
  • A virtual Scenario has not been answered yet:

How to support conventional IPv4 applications in IPv6 only network without encapsulation

IPv4 IPv6 Dual stack

IPv6-only

IPv6 APP | IPv4 APP

Dual stack

IPv6 APP | IPv4 APP

Dual stack

IPv6-only

IPv6 APP | IPv4 APP

Dual stack

IPv6 APP | IPv4 APP

… (by Sheng Jiang)

slide-6
SLIDE 6

Scenarios (H1 talk with H2)

  • H1 could know H2’s address either by DNS or referal, but H1’s application

has no idea how to setup the tunnel between H1 and H2.

  • Communication between H1 and H2 could be 4-4,4-6, and 6-4
  • Direct IPv6 routing will benefit for such communication

H1 H2 IPv6 only network

4-6/4-4/6-4

IPv4 network H3

IPv4 app Server

PNAT64

6-4/4-4 IPv4 appIPv6 app IPv4 Stack IPv6 Stack IPv4 appIPv6 app IPv4 Stack IPv6 Stack

Scenarios we consider are multiple possibilities:

  • PNAT44COM: IPv4-IPv4 application communicate within/through IPv6 network;
  • PNAT46COM: IPv4-IPv6 application communicate within/through IPv6 network
  • PNAT64COM: IPv6-IPv4 application communicate within/through IPv6 network
slide-7
SLIDE 7

IPv6 Appl. IPv4 Appl.

PNAT modules

TCP/UDP/IPv4-6

Network card driver

Socket API

Network Scenarios

IPv6 site

Scenarios Descriptions PNAT Host(IPv4 app) <—> IPv4 server PNAT44COM PNAT Host 1(IPv4 app) <—> PNAT Host 2(IPv4 app) PNAT64 IPv6 Appl. IPv4 Appl.

PNAT modules

TCP/UDP/IPv4-6

Network card driver

Socket API

PNAT Host 2 PNAT Host 1

DNSv6 DNSv4

IPv4 site IPv4 server

Access Router (DHCPv6) Scenarios Descriptions PNAT46COM PNAT Host 1(IPv4 app) <—> PNAT Host 2(IPv6 app) PNAT64COM PNAT Host 1(IPv6 app) <—> PNAT Host 2(IPv4 app) PNAT66COM PNAT Host 1(IPv6 app) <—> PNAT Host 2(IPv6 app)

slide-8
SLIDE 8

Why we need host based translation

– How to support conventional IPv4 applications in IPv6

  • nly network, IPhone store already has more than

60,000 applications. – The implementation of operator’s service has been long-time running, quite stable, and hard to upgrade. – Modify the host is very difficulty, but modify the host’s network stack is not that difficulty. – Operator customize the host more than before.

slide-9
SLIDE 9

Translation in the host vs in the network

  • The first hop of the network is IPv6 only
  • The major difference:

– Supporting the conventional IPv4 application is mandatory requirement for the operators.

slide-10
SLIDE 10

Translation vs Tunneling

  • This is not comparison between them, but for

special host scenarios.

  • The difference:

– Communication need to be directly route each other to avoid tunnel mesh, other than passing through the tunneling aggregation point. (CGN) – Different IP families need to talk each other.

slide-11
SLIDE 11

PNAT vs Dual-stack Lite

  • The major difference:

– Within IPv6 network communication, it need not go through any CGN. – 3GPP QoS will be based out IP header other than inside IP header – For MTU, translation is a little better than tunneling. – DNS synthesis problems - DNSSEC relations?

slide-12
SLIDE 12

Compatible with NAT64, not DNS64

  • The current framework document assumes that

DNS queries go to a DNS64 if sent over an IPv6-only network. Is there a reason to change this assumption?

– PNAT is compatible with NAT64, but it doesn’t compatible with DNS64, the reason is PNAT host need to identify the peer side IP type.

slide-13
SLIDE 13

Avoid double NAT issue

  • http://tools.ietf.org/html/draft-durand-v6ops-

natv4v6v4-01.

– Since PNAT could identify the peer side IP type based on DNS resolve result, so it could know whether it need do ALG inside the host or not, the issue has been avoided.

slide-14
SLIDE 14

PNAT module in the host

PNAT Socket Translation Host modules LIR prefix will be used for PNAT source address translation Well-know prefix will be used for PNAT destination address translation LIR prefix will be used for PNAT source address translation Well-know prefix will be used for PNAT destination address translation

  • PNAT inside the host will translate

IPv4 socket API into IPv6 socket API

  • DNS IPv4 socket call can be

translated into IPv6 socket call

slide-15
SLIDE 15

Two possible ways to perform DHCPv6 process

  • PNAT host request IPv4 address , IPv6 prefix , both

DNS4 and DNS6 server address from DHCPv6 server. There are two methods to achieve the goals

Method 1: container

  • ption for server

configuration Thanks the discussion from James woodyatt

Server

RG client SP DHCP server

Host Host Host

Host

DHCP Server

Method 2: extension of DHCPv6 option to support assigning IPv4 address; For IPv6 prefix, RFC 3633 could be used

  • 1. solicit message

2 . Advertise

  • 3. Request message
  • 4. Reply message

Container option IPv4 address option

slide-16
SLIDE 16

PNAT Address translation and PNAT64

  • perations
  • For the destination address
  • For the source address, all zero in 65-96

bits is to identify the case of private IPv4 address embedded

  • For the source address, all one in 65-96

bits is to identify the case of public IPv4 address embedded

PNAT address translation PNAT64 operations

Destination addr Actions WKP:: perform a translation operation Source addr Actions Padding all one in 65-96 bits Get rid of prefix, record the relationship between IPv4 address and IPv6 prefix Padding all zero in 65-96 bits A normal NAT64 procedure Normal IPv6 address A normal NAT64 procedure

slide-17
SLIDE 17

PNAT44COM signaling (private IPv4 address embedded in source address)

Socket translation Address translation

PNAT host

DNS6 Server PNAT64 IPv4 Server 22.1.1.1 IPv4 app. DNS4 call gethostbyname() {DNS soc translation

  • >getaddrinfo()}

DNS query (AAAA/A) Transmit data Socket translation-> connect(); send()… Socket translation-> accept();recvmsg()… DNS4 response 10.1.1.1 22.1.1.1 S: LIR:0:0:a01:101 D: WKP::1601:101:: IPv6 header + IPv4 Payload S: 33.1.1.1 D: 22.1.1.1 Public address pool 33.1.1.1 ~33.255.1.1 S: 22.1.1.1 D: 33.1.1.1 22.1.1.1 10.1.1.1 DHCP DHCP discovery

  • ffer=LIR:: (IPv6 prefix)+10.1.1.1(IPv4)+DNS4/6 address

S: LIR:0:0:a01:101 D: WKP::b01:101:: DNS4 Server 11.1.1.1 S: 33.1.1.1 D: 11.1.1.1 DNS response (A: 22.1.1.1) Synthesize WKP S: WKP::1601:101:: D: LIR:0:0:a01:101 Identify peer’s IP type If it’s IPv4, send DNS query to DNS4 server Synthesize WKP A normal NAT64 handling (ALG if it is needed ) A normal NAT64 handling (ALG if it is needed )

slide-18
SLIDE 18

Socket translation Address translation

PNAT host

DNS6 Server PNAT64 IPv4 Server 22.1.1.1 IPv4 app. DNS4 call gethostbyname() {DNS soc translation

  • >getaddrinfo()}

DNS query (AAAA/A) Transmit data Socket translation-> connect(); send()… Socket translation-> accept();recvmsg()… DNS4 response IPv6 header + IPv4 Payload DHCP DHCP discovery

  • ffer=LIR:: (IPv6 prefix)+33.1.1.1(IPv4)+DNS4/6 address

DNS4 Server 11.1.1.1 DNS response (A: 22.1.1.1) Synthesize WKP Identify peer’s IP type If it’s IPv4, send DNS query to DNS4 server Synthesize WKP A normal NAT64 handling (ALG if it is needed ) A normal NAT64 handling (ALG if it is needed )

PNAT44COM signaling (public IPv4 address embedded in source address)

No demand for maintaining public address pool S: LIR:ffff:ffff:2101:101 D: WKP::b01:101:: S: 33.1.1.1 D: 11.1.1.1 33.1.1.1 22.1.1.1 S: LIR:ffff:ffff:a01:101 D: WKP::1601:101:: S: 33.1.1.1 D: 22.1.1.1 S: 22.1.1.1 D: 33.1.1.1 22.1.1.1 33.1.1.1 S: WKP::1601:101:: D: LIR:ffff:ffff:a01:101

slide-19
SLIDE 19

Next?

  • We are doing the implementation, more than 5

vendors are involved in, hope we can finish by the early of Nov. this technology will be deployed in our network hopefully within this year, for IPv6 based HDTV service.

  • Will Behave WG consider to have host based

translation solution work item?

  • How to proceed this work? (To chairs)
slide-20
SLIDE 20

Appendix PNAT vs (BIA or BIS)

  • The difference:

– There are no demands to retain mapping table in PNAT44COM, but BIA/BIS still needs – PNAT described in detail how it work together with PNAT64, but BIA/BIS doesn't. – PNAT host and PNAT64 will process differently for public and private IPv4 source address, but BIA/BIS couldn’t. – PNAT can identify peer application type (4 or 6) by responded A

  • r AAAA records, so knows whether the host need to do ALG or

not which could avoid NAT464 issue.