Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-11.txt

From: [email-masked]
Date: Mon, 30 Jul 2012 14:16:24 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Discovery of IPv6 Prefix Used for IPv6 Address Synthesis
	Author(s)       : Teemu Savolainen
                          Jouni Korhonen
                          Dan Wing
	Filename        : draft-ietf-behave-nat64-discovery-heuristic-11.txt
	Pages           : 18
	Date            : 2012-07-30

Abstract:
   This document describes a method for detecting the presence of DNS64
   and for learning the IPv6 prefix used for protocol translation on an
   access network.  The method depends on the existence of a well-known
   IPv4-only domain name "ipv4only.arpa".  The information learned
   enables nodes to perform local IPv6 address synthesis and to
   potentially avoid NAT64 on dual-stack and multi-interface
   deployments.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-11

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-nat64-discovery-heuristic-11

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked]
Date: Tue, 31 Jul 2012 15:59:19 +0800

Hi,

   I have a little doubt about the draft.

   In section 3, 
   "
    REQ-11:  When a CGN is unable to create a mapping due to resource
            constraints or administrative restrictions (i.e., quotas):

            A.  it MUST drop the original packet;

            B.  it SHOULD send an ICMP Destination Unreachable message
                with code 1 (Host Unreachable) to the sender;

            C.  it SHOULD send a notification (e.g., SNMP trap) towards
                a management system (if configured to do so);

            D.  and it MUST NOT delete existing mappings in order to
                "make room" for the new one.  (This only applies to
                normal CGN behavior, not to manual operator
                intervention.)
    "

    In item D, In my opinion, a static mapping MAY be created without 
recieving the datagram, but the static rule has been configured AND the 
corresponding user be online. Under the circumstances, if the packet a CGN 
recieved match the STATIC rule , it SHOULD DELETE a existing DYNAMIC 
mapping in order to "make room" for the STATIC mapping, because of 
ensuring the STATIC rule taking effect.
    Otherwise, how to resolve the problem instead of kicking a DYNAMIC 
mapping off ?
    On the other hand, if the packet need to be translated by ALG, it MAY 
create two mappings but it find that there is "no room" to create the 
second mapping after having created the first mapping.

    Thanks,
    Wei Meng
    ZTE corporation

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.