Subject: [addr-select-dt] Fwd: draft slides for behave meeting ( learning NAT64 prefix)

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 26 Jul 2010 15:23:21 +0900

Hi all,

I've forwarded the following thread from Teemu.
This looks like about NAT64 prefix prioritization especially in comparison with IPv4.

Maybe I should include this issue in the slides for 6man.

Any thoughts ?

Begin forwarded message:

> From:  <[email-masked]>
> Date: 2010年7月23日 19:08:54JST
> To:  <[email-masked]>, <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
> Subject: RE: draft slides for behave meeting ( learning NAT64 prefix)
> 
> Hi,
> 
>> Keep in mind that I am trying to tease out what "more" is there, so we
>> can get it into the presentation on Monday.
> 
> Hopefully the community comes up with ideas/scenarios as well - quite like Matthew Kaufman commented on the list already.
> 
>> If it's just a preference thing, adjusting RFC3484 rules (in the
>> connection manager, or elsewhere) to prefer IPv4 over synthetic
>> IPv6 addresses would do the trick.
> 
> Right, Arifumi probably is the best person to tell if 6man's source address selection design team has already taken into account the case where addresses matching to NSP (and WKP) should (perhaps) have lower preference? 
> 
>> But it seems it is more than a preference thing.  For reasons that
>> I do not fully yet grasp, you want to know on a response-by-response
>> basis if an address is synthesized, by having additional bits sent
>> to the handset.
> 
> This is part of pros and cons of different approaches. If a network is using multiple different prefixes for NAT64, then it might be easier to have the indication in each reply rather than communicate set of prefixes for hosts?
> 
> Best regards,
> 
> Teemu
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Jul 2010 10:24:04 +0100

One point is what is the 'best' default policy is for 3484-bis?    Preferring native IPv4 over NAT64 seems sensible, just as preferring IPv4 over 6to4 or Teredo would be, but I don't know the context of your discussion.

The other is that this shows again the value of progressing the enterprise policy distribution mechanism so whatever 3484-bis says when a new issue arises the enterprise can handle it via the mechanism offering updated policy to hosts.

Tim

On 26 Jul 2010, at 07:23, Arifumi Matsumoto wrote:

> _______________________________________________
> addr-select-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/addr-select-dt