> -----邮件原件-----
> 发件人: [email protected] [mailto:[email protected]] 代表 Dan Wing
> 发送时间: 2010年1月6日 6:51
> 收件人: 'Jari Arkko'
> 抄送: [email protected]; 'IETF IPv6
> Mailing List'
> 主题: RE: AD review of draft-ietf-6man-text-addr-representation
>
>
>
> > -----Original Message-----
> > From: Jari Arkko [mailto:[email protected]]
> > Sent: Tuesday, January 05, 2010 2:39 PM
> > To: Dan Wing
> > Cc: 'Seiichi Kawamura';
> > [email protected];
> > 'IETF IPv6 Mailing List'
> > Subject: Re: AD review of draft-ietf-6man-text-addr-representation
> >
> > Dan, Seiichi,
> >
> > > Perfect.
> > >
> >
> > Good, but I don't think we're done. I still need more people
> > commenting
> > on the trade-offs between the different approaches (my mail from Dec
> > 28th). Dan, you commented on the approach #3 and how tool options can
> > make it more practical. But you didn't explicitly say which
> > approach you
> > prefer. Is your preference #3, and if so, why?
>
> Your email from January 28:
> http://www.ietf.org/mail-archive/web/ipv6/current/msg11215.html,
> summarized:
>
> 1) Mandate that the text representation is <SOMETHING>
> and never changes after this.
>
> 2) Mandate that the text representation is <SOMETHING>
> but take into account new WKPs.
>
> 3) Mandate that the text representation is <SOMETHING>
> but require that external mechanisms help recognize
> even dynamically assigned IPv4/IPv6 prefixes.
>
> 4) As above, but specify a mandatory external mechanism.
>
>
> Yes, my preference is #3.
>
> We have #1 today, which is the ::ffff/96 prefix.
>
> We know that BEHAVE is creating two new prefixes:
>
> 1. an IANA-assigned Well-Known Prefix. This is fixed and could be
hardcoded
> into software) which is your #2.
>
> 2. a network-specific prefix. This is variable, and will be a different
> prefix on every network. This can be supported by your #3.
>
> Regarding your #4, I do not believe we are ready to specify a mandatory
way
> to
> learn a network translator's prefix. And I say that as author of
> draft-wing-behave-learn-prefix (which proposes using DHCPv6 and DNS) and
my
> awareness of draft-bcx-behave-learn-address (which proposes using IPv6
RAs).
If my memory is correct, using IPv6 RA for prefix64-learning was initially
proposed in [I-D.wing-behave-learn-prefix]. However, it was removed from the
-04 version of that draft.
[I-D.wing-behave-learn-prefix]
Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix
of an IPv6/IPv4 Translator",
draft-wing-behave-learn-prefix-02 (work in progress),
May 2009.
Xiaohu
> Furthermore, analysis of a network trace (e.g., using tcpdump) might be
> performed on a different network anyway, so learning the prefix of *my*
> network's NAT64 isn't helpful; I need to tell my tool the prefix of the
NAT64
> that was being used when the network trace was collected (example: a
customer
> of Cisco's sends us a network trace, and we need to analyze it. The tool
> would need to be told the customer's NAT64 prefix (which could be the WKP
or
> their NSP) not Cisco's NAT64 prefix (which could be the WKP or our NSP).
>
> Hope that helps.
> -d
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
