Subject: [BEHAVE] WGLC: draft-ietf-behave-nat64-learn-analysis-00

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Jul 2011 14:09:36 -0700

This starts a 3 week WGLC (extra time to accommodate IETF travel) for
draft-ietf-behave-nat64-learn-analysis-00.  This document analyzes the
available approaches for a host to learn its NAT64 prefix.  Abstract:

   Hosts and applications may benefit from the knowledge if an IPv6
   address is synthesized, which would mean a NAT64 is used to reach the
   IPv4 network or Internet.  This document analyses a number of
   proposed solutions for communicating whether the synthesis is taking
   place, used address format, and the IPv6 prefix used by the NAT64 and
   DNS64.  The solutions enable both NAT64 avoidance and intentional
   utilization by allowing local IPv6 address synthesis.  The document
   concludes by recommending selection of heuristic discovery based
   solution.

Please send comments to [email-masked].  WGLC ends in 3 weeks on 
August 12.

-d

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 27 Jul 2011 12:38:03 -0700 (PDT)

Hi,
  I have a comment for Section 4.9.1. 
I couldn't understand how the NAS entities would come to know the NSPs? 
Why is GTP not needed here?

Regards,

Behcet

> _______________________________________________
> Behave  mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 28 Jul 2011 17:59:19 +0300

> Why is GTP not needed here?

Does it really matter here? Non-Access-Stratum (NAS) signaling was given as an example of an existing transport/container how to get the required information into the end host on a specific link type. We could use IPV6CP in case of PPP etc. Where the configuration information originates is secondary as long as it passed around to relevant element in a _system_specific_ means. In EPS case that would probably involve a non-trivial combination of NAS, AAA and GTP-C/PMIPv6 signaling. See the first CON in Section 4.9.2 about the downside of the Section 4.9.1 approach.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 28 Jul 2011 13:21:21 -0700 (PDT)

> Does it really matter here? Non-Access-Stratum (NAS)  signaling was given as an 
>example of an existing transport/container how to get  the required information 
>into the end host on a specific link type. We could use  IPV6CP in case of PPP 
>etc. Where the configuration information originates is  secondary as long as it 
>passed around to relevant element in a _system_specific_  means. In EPS case 
>that would probably involve a non-trivial combination of NAS,  AAA and 
>GTP-C/PMIPv6 signaling. 
>

For the sake of giving a complete view of what is needed, including the above 
(or some similar text) in the draft would be good.

Behcet
>See the first CON in Section 4.9.2 about the  downside of the Section 4.9.1 
>approach.
> 
> 
> - Jouni
> 
> 
> 
> > 
> > Regards,
> > 
> > Behcet
> > 
> > 
> >>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 29 Jul 2011 01:25:42 +0300

> (or some similar text) in the draft would be good.

Ok. I'll figure out something and post it later on the list.

- JOuni

---

From: jouni korhonen <[email-masked]>
Date: Fri, 29 Jul 2011 01:27:54 +0300

- JOuni