headers
David Harrington | 4 Aug 2011 00:50
Picon

AD review of draft-ietf-behave-v4v6-bih-05

Hi,

Below is the AD review of draft-ietf-behave-v4v6-bih-05.
Most are editorial comments.
Some are RFC2119-related.
Some are simply questions I would like answered, and the answer might
be best in the document so other readers know the answers as well.

===

AD review of draft-ietf-behave-v4v6-bih-05 

The abstract or section 1.1 should explain WHY a successor is needed.

2.1 refers to Appendix B; there is no appendix B.

Typically appendices are used for non-normative content, but this
appendix lists functions that MUST be intercepted (according to 2.1).
This would probably be better placed in the main part of the document.

2.1 says the APIs MUST be intercepted; the Appendix says they SHOULD
be intercepted. Which is it?

2.2 says "Protocol translation SHOULD NOT be performed for IPv4
packets sent to the IPv4 address range used by local synthesis and for
which a mapping table entry does not exist. The implementation SHOULD
attempt to route such packets via IPv4 interfaces instead." Why should
and not MUST? Is should, what ar ethe valid exceptions to the
recommended practice?
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Harrington | 4 Aug 2011 02:12
Picon

Closing the behave WG

Hi,

As Responsible Area Director, I have received a request from the
behave WG chairs to consider closing the behave working group, rather
than rechartering to do additional work.

The chairs and the IESG agree that closing the WG after completing the
current milestones would be a good thing, to signal that the chartered
behave work items supporting transition to IPv6 have been completed.

During ietf81, the chairs discussed with the working group the
possible closing of the working group. Additional work, such as those
drafts identified in the chairs' slides, can be proposed for
completion in existing working groups (or in new working groups). None
of this would be automatic; the proponents would need to convince an
existing WG to adopt their draft, or would need to convince the IESG a
new working group is justified using the normal methods for requesting
a new working group. The behave chairs have agreed to serve as
technical advisors to working groups that take on such work, if
needed. 

In my opinion, the sense of the room was to support this closure. 

As Responsible area director, I plan to make a decision on WG closure
in the next few weeks, and would like to give the WG mailing list
members a chance to provide feedback on this proposed closure. Please
send substantive comments to the
behave <at> ietf.org mailing list by 2011-08-15, with the above Subject
line.
(Continue reading)

Permalink | Reply | 34 comments |
headers
Reinaldo Penno | 4 Aug 2011 09:58
Favicon

Re: Closing the behave WG


On 8/3/11 5:12 PM, "David Harrington" <ietfdbh <at> comcast.net> wrote:

> Hi,
> 
> As Responsible Area Director, I have received a request from the
> behave WG chairs to consider closing the behave working group, rather
> than rechartering to do additional work.
> 

I vote for rechartering. There is very important work to be done in this
area, specially given the CGN traction in the market. I would like to see at
least the following drafts published.

http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-02
https://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-00

> The chairs and the IESG agree that closing the WG after completing the
> current milestones would be a good thing, to signal that the chartered
> behave work items supporting transition to IPv6 have been completed.

I understand BEHAVE have been around for a while and if it is taking a lot
of the chairs' time maybe we could consider changing the chairs for the next
rechartering. 

> 
> During ietf81, the chairs discussed with the working group the
> possible closing of the working group. Additional work, such as those
> drafts identified in the chairs' slides, can be proposed for
> completion in existing working groups (or in new working groups).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Xuxiaohu | 4 Aug 2011 11:47
Favicon

Re: Closing the behave WG

I'm also in favor of rechartering due to the same reason mentioned by Reinaldo, that is, there is still a lot
of very important work to be done in this area. 

Since CGNs are usually deployed in ISP networks or large enterprise networks, rather than in home
networks, and these devices usually carry a large volume of traffic and users, high availability and
load-balancing are much desirable features for most CGN operators. Although proprietary solutions are
available to some extent, vendor lock-in and simultaneous failure due to the same bug are two
side-effects with such proprietary solutions, which are not much acceptable to some operators. Hence I
do suggest the WG could reconsider these two important features for CGNs if/when rechartering.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] 代表
> Reinaldo Penno
> 发送时间: 2011年8月4日 15:58
> 收件人: David Harrington; behave <at> ietf.org
> 主题: Re: [BEHAVE] Closing the behave WG
> 
> 
> 
> 
> On 8/3/11 5:12 PM, "David Harrington" <ietfdbh <at> comcast.net> wrote:
> 
> > Hi,
> >
> > As Responsible Area Director, I have received a request from the
> > behave WG chairs to consider closing the behave working group, rather
> > than rechartering to do additional work.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Perreault | 4 Aug 2011 14:58
Picon
Favicon

Re: Closing the behave WG

On 2011-08-03 20:12, David Harrington wrote:
> In my opinion, the sense of the room was to support this closure. 

I disagree. Several people went to the mic to talk about additional work
that needs to be done. In addition, I think many authors of drafts that
were on the "potential additional work" slides were not at this meeting.

Personally, I've stated at the mic that the CGN logging issue is very
important to many people right now and that there is a need for a
standard solution. There are at least two drafts currently trying to
address this issue. We have the right people in behave right now to
address this problem. Moving this work to another working group would be
detrimental.

Simon
--

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
Permalink | Reply | 5 comments |
headers
Stan Barber | 4 Aug 2011 15:47
Favicon
Gravatar

Re: Closing the behave WG

I also agree there is much work still on the table for this group.

If not done in BEHAVE, is there another place this work could be done?

On Aug 4, 2011, at 8:58 AM, Simon Perreault wrote:

> On 2011-08-03 20:12, David Harrington wrote:
>> In my opinion, the sense of the room was to support this closure. 
> 
> I disagree. Several people went to the mic to talk about additional work
> that needs to be done. In addition, I think many authors of drafts that
> were on the "potential additional work" slides were not at this meeting.
> 
> Personally, I've stated at the mic that the CGN logging issue is very
> important to many people right now and that there is a need for a
> standard solution. There are at least two drafts currently trying to
> address this issue. We have the right people in behave right now to
> address this problem. Moving this work to another working group would be
> detrimental.
> 
> Simon
> -- 
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> Behave mailing list
> Behave <at> ietf.org
> https://www.ietf.org/mailman/listinfo/behave
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cameron Byrne | 4 Aug 2011 17:12
Picon

Re: Closing the behave WG

I disagree that it should be closed and suggest that the nat464 (as described in pnat, 4v6, and bih) be properly named nat464, generalized, and brought into this group, softwire is not the right place. It is a shame that nat464 has such a bad name that the concept has to be veiled in various other specs

Cb

<div>
<p>I disagree that it should be closed and suggest that the nat464 (as described in pnat, 4v6, and bih) be properly named nat464, generalized, and brought into this group, softwire is not the right place. It is a shame that nat464 has such a bad name that the concept has to be veiled in various other specs</p>

<p>Cb</p>
</div>
Permalink | Reply | 19 comments |
headers
teemu.savolainen | 4 Aug 2011 20:31
Picon

Happy Eyeballs and DNS64 not sending synthetic AAAA RRs

Hi,

 

RFC6147 section 5.1.1 says DNS64 “SHOULD NOT” include synthetic AAAA RRs in the response if real AAAA records are available.

 

Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize AAAA RRs when real AAAA records are available, the host would then be able to fall back using IPv4 in case real IPv6 connectivity on the path to dual-stack enabled destination is broken/not-good…

 

I.e. as of now DNS64 by default completely hides dual-stack destinations’ IPv4 addresses and hence makes it impossible for hosts to fallback to IPv4.. right?

 

Of course returning synthetic AAAA RRs could make hosts accidentally communicate through NAT64s.. but we have the tools under work that would help hosts to prefer non-synthetic addresses during address selection functionsJ

 

If IPv6 and IPv4 path characteristics would be different enough, it might make sense for hosts to do happy eyeballs even when in IPv6-only connection by triggering both native IPv6 and NAT64-traversing transport sessions.. but hosts can’t if DNS64 hides the IPv4 address… except by performing WKP/NSP discovery as documented and then starting local IPv6 address synthesis procedures for happy eyeballs purposesJ

 

Just some thoughtsJ

 

Best regards,

 

Teemu

<div>
<div class="WordSection1">
<p class="MsoNormal">Hi,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">RFC6147 section 5.1.1 says DNS64 &ldquo;SHOULD NOT&rdquo; include synthetic AAAA RRs in the response if real AAAA records are available.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize AAAA RRs when real AAAA records are available, the host would then be able to fall back using IPv4 in case real IPv6 connectivity on the path to dual-stack enabled
 destination is broken/not-good&hellip;<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">I.e. as of now DNS64 by default completely hides dual-stack destinations&rsquo; IPv4 addresses and hence makes it impossible for hosts to fallback to IPv4.. right?<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Of course returning synthetic AAAA RRs could make hosts accidentally communicate through NAT64s.. but we have the tools under work that would help hosts to prefer non-synthetic addresses during address selection functions<span>J</span>
<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">If IPv6 and IPv4 path characteristics would be different enough, it might make sense for hosts to do happy eyeballs even when in IPv6-only connection by triggering both native IPv6 and NAT64-traversing transport sessions.. but hosts can&rsquo;t
 if DNS64 hides the IPv4 address&hellip; except by performing WKP/NSP discovery as documented and then starting local IPv6 address synthesis procedures for happy eyeballs purposes<span>J</span><p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Just some thoughts<span>J</span><p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Best regards,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Teemu<p></p></p>
</div>
</div>
Permalink | Reply | 10 comments |
headers
Marc Blanchet | 4 Aug 2011 20:37
Picon
Favicon

Re: Happy Eyeballs and DNS64 not sending synthetic AAAA RRs


Le 2011-08-04 à 14:31, <teemu.savolainen <at> nokia.com> a écrit :

> Hi,
>  
> RFC6147 section 5.1.1 says DNS64 “SHOULD NOT” include synthetic AAAA RRs in the response if real AAAA
records are available.
>  
> Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize AAAA RRs when real AAAA
records are available, the host would then be able to fall back using IPv4

I'm not sure I get your point. If we are in a DNS64 scenario, the network between host and the NAT64, as well as
the host itself,  is IPv6-only. Therefore, there is no such "fall back using IPv4".  

Unless I don't understand your point.

Marc.

> in case real IPv6 connectivity on the path to dual-stack enabled destination is broken/not-good…
>  
> I.e. as of now DNS64 by default completely hides dual-stack destinations’ IPv4 addresses and hence
makes it impossible for hosts to fallback to IPv4.. right?
>  
> Of course returning synthetic AAAA RRs could make hosts accidentally communicate through NAT64s.. but
we have the tools under work that would help hosts to prefer non-synthetic addresses during address
selection functionsJ
>  
> If IPv6 and IPv4 path characteristics would be different enough, it might make sense for hosts to do happy
eyeballs even when in IPv6-only connection by triggering both native IPv6 and NAT64-traversing
transport sessions.. but hosts can’t if DNS64 hides the IPv4 address… except by performing WKP/NSP
discovery as documented and then starting local IPv6 address synthesis procedures for happy eyeballs purposesJ
>  
> Just some thoughtsJ
>  
> Best regards,
>  
> Teemu
> _______________________________________________
> Behave mailing list
> Behave <at> ietf.org
> https://www.ietf.org/mailman/listinfo/behave
Permalink | Reply | 9 comments |
headers
teemu.savolainen | 4 Aug 2011 20:47
Picon

Re: Happy Eyeballs and DNS64 not sending synthetic AAAA RRs

> > RFC6147 section 5.1.1 says DNS64 "SHOULD NOT" include synthetic AAAA
> RRs in the response if real AAAA records are available.
> >
> > Reflecting Happy Eyeballs discussions: should DNS64 actually synthesize AAAA
> RRs when real AAAA records are available, the host would then be able to fall
> back using IPv4
> 
> I'm not sure I get your point. If we are in a DNS64 scenario, the network
> between host and the NAT64, as well as the host itself,  is IPv6-only. Therefore,
> there is no such "fall back using IPv4".
> 
> Unless I don't understand your point.

The address family related issues can occur in the access network or elsewhere in the Internet, right? 

If the IPv6 problem is outside of the IPv6-only access network, the eyeballs might in theory be happier if
data would traverse through NAT64 and to the IPv4 Internet path to the destination..

I wrote "just some thoughts" because this is theoretical thinking, not some real life IPv6 transport
network problems I would've seen:)

Teemu
Permalink | Reply | 1 comment |

Gmane