Jari Arkko | 2 Feb 2010 18:47

INT BOFs

We only had one BOF proposal this time (see 
http://tools.ietf.org/bof/trac/wiki/WikiStart)

The one proposal that we had was not for a WG forming BOF, but a 
discussion slot to talk about IPv6 transition in mobile networks and 
mobility protocols. We've decided to not have a BOF about this, but 
allocate time in the INTAREA meeting for that discussion.

Jari & Ralph
Jari Arkko | 2 Feb 2010 18:48

agenda items for Anaheim


Please send suggestions for agenda items to the ADs. So far I have only 
one item on the planned agenda -- a discussion about IPv6 transition, 
mobile networks, and mobility protocols. We plan to discuss the outcome 
of the 3GPP-IETF joint meeting and whether there's any remaining work to 
do in the mobility space with regards to IPv6 transition tools.

Jari

P.S. For the record, we have almost completed the assignment of new 
chairs for the INTAREA WG, just pending some final confirmations now. In 
the future these e-mails will be sent by them.
Marc Blanchet | 8 Feb 2010 22:04
Picon
Favicon

announcing DNS64-NAT64 opensource implementations

<sorry for cross-posting/>

This is to announce the availability of two NAT64-DNS64 open-source
implementations by Viagenie, as follows:

======
NAT64
======
BSD PF:
  this implementation of NAT64 is made by modifying the PF packet filter
available on BSD systems. A new 'nat64' statement is created in the
pf.conf file to enable the nat64 functionality.

Linux Netfilter:
The implementation of NAT64 for linux is available as a kernel module.
It uses Netfilter's facilities for packet interception.  The
configuration is done with parameters provided at module insertion.

======
DNS64
======
As announced in july 2009 during IETF Stockholm, the companion DNS64
functionality is also available in two implementations, as follows:

BIND:
  this implementation of DNS64 is made by modifying the BIND DNS server.
A new "dns64-prefix" statement in options is created in the named.conf
file to enable DNS64 functionality.

Unbound:
(Continue reading)

Azinger, Marla | 5 Feb 2010 00:27

Draft input requested for draft-azinger-additional-private-ipv4-space-issues-02

Hello-
 
We have produced a draft document that summarizes the IPv4 Private IP Address issues and alternatives that we face today.  We believe this document belongs in OPSAWG however we would like input from more of the community and for this reason we are posting it to V6OPS and INTAREA mail lists.
 
The draft can be found at:

http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-02

Thank you for your time

Marla Azinger & Leo Vegoda

_______________________________________________
Int-area mailing list
Int-area <at> ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Bob Hinden | 12 Feb 2010 22:12
Picon

Re: Draft input requested for draft-azinger-additional-private-ipv4-space-issues-02

Marla,

On Feb 4, 2010, at 3:27 PM, Azinger, Marla wrote:

> Hello-
>  
> We have produced a draft document that summarizes the IPv4 Private IP Address issues and alternatives
that we face today.  We believe this document belongs in OPSAWG however we would like input from more of the
community and for this reason we are posting it to V6OPS and INTAREA mail lists.
>  
> The draft can be found at:
> http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-02
> 

In Section 4.2, IPv6 Unique Local Addresses are described as having local scope.  This isn't correct.  From
Section 3.3 of RFC4193:

   By default, the scope of these addresses is global.  That is, they
   are not limited by ambiguity like the site-local addresses defined in
   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
   their applicability is greater than site-local addresses.  Their
   limitation is in the routability of the prefixes, which is limited to
   a site and any explicit routing agreements with other sites to
   propagate them (also see Section 4.1).  Also, unlike site-locals, a
   site may have more than one of these prefixes and use them at the
   same time.

Regards,
Bob
hannu.hietalahti | 15 Feb 2010 11:49
Picon

Updated 3GPP - IETF dependency document

Dear RAI, INT,
 
the 3GPP - IETF dependency document has been updated at: http://www.3gpp.org/IETF-Dependencies-and-Priorities
 
BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724
 
 
_______________________________________________
Int-area mailing list
Int-area <at> ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Ralph Droms | 18 Feb 2010 13:13
Picon
Favicon

intarea WG chairs

We're very pleased to announce that Julien Laganier and Christian Vogt
have agreed to become co-chairs of the intarea WG.  Thanks to Julien
and Christian for taking on these positions.  Jari and I are looking
forward to working with them as we formalize the intarea WG.

We are making final edits on the WG charter and will publish it soon.
Julien and Christian will manage the intarea WG meeting agenda for
Anaheim, and are accepting requests for agenda slots.

- Jari and Ralph
hannu.hietalahti | 19 Feb 2010 13:25
Picon

Minutes of 3GPP - IETF teleconference 17th Feb 2010

Dear all,
 
please find below the meeting minutes from the 3GPP - IETF teleconference on the 17th of February 2010. The same minutes are shared on four mailing lists: 3GPP TSG CT, IETF RAI, INT, OPS.
 
Dependency document on 3GPP website will be updated soon for the coming March TSG plenaries.
 
Date: 17th Feb 2010
Time: 16:00 – 18:00 UTC
Venue: Phone conference
Participants:
Hannu Hietalahti (notetaker)
Milan Patel
Atle Monrad
Gonzalo Camarillo
Tom Tailor
Scott Lawrence
Hannes Tschofenig
Mary Barnes
Adam Roach
Jari Arkko
Ben Campbell
Julien Laganier
Spencer Dawkins
Ralph Droms
Marc Linsner
 
Agenda:
-------------
1. Roll call
2. Review of action points
3. Joint workshop on IPv6 in March 2010
4. IANA registrations
5. Emergency calls
6. Review of 3GPP IETF dependency document
7. Next meeting
8. AOB
9. Closing
 
 
1.      Roll call
All participants are listed above.
 
2.      REview of action points
AP Title Responsible Status
1 Request expert comments on the best approach to IANA registration of Service ID namespace assignment Mary Barnes Closed
2 Check the registration status of IANA registration of 3gpp-ims+xml Cullen Jennings Closed
3 Provide a written explanation of why it could be considered that IANA registration of feature tags g.3gpp.icsi and g.3gpp.iari could proceed according to RFC 2506 without procedural change Atle Monrad Closed
4 Escalate the previous summary by Atle for RAI leadership review during IETF #74 to find a recommended way forward Cullen Jennings Closed
5 Report the SA3 meeting outcome to Jari Arkko Valtteri Niemi Closed
6 Arrange a telco on media security on Friday the 7th of Nov 2008 Valtteri Niemi Closed
7 Find the original 3gpp-ims+xml registration document and forward it to Cullen Hannu Hietalahti Closed
8 Set up a meeting between 3GPP and IETF to agree how to proceed in the IANA registration of feature tags g.3gpp.icsi and g.3gpp.iari Gonzalo Camarillo Closed
9 Check the real 3GPP need for draft-arkko-mext-rfc3775-altcoa-check Raj Patil Closed
10 Hannu to ask on CT1 mailing list if anyone knows any reason why phonebcp –draft would not be applicable in cellular environment Hannu Closed
  New APs assigned in this meeting    
11 Check the status of IANA registration of EAP-AKA attributes required by 3GPP Jari Arkko done
12 Jari Arkko as the sponsor of draft-das-mipshop-andsf-dhcp-options needs to know of any changes in the requirements from 3GPP side where the discussion on the 3GPP TS 24.302 requirements for ANDSF discovery are still ongoing. Hannu to inform Jari of 3GPP decisions in this area. Hannu Hietalahti Open
13 The status of draft-mmusic-ice-tcp is marked dead in I-D Tracker, but a new version has been since then submitted. Hannu to find out from the responsible AD (Cullen) whether 3GPP should expect the draft to remain dead or not? Hannu Hietalahti done
14      
 
 
3.      Joint workshop in March 2010
The planning of IPv6 migration workshop in San Francisco on 1 – 2 March 2010 is well underway by the co-chairs Fred Baker and Balazs Bertenyi.
 
This workshop is informative and any agreements still need to be documented according to normal working procedures in IETF or 3GPP or both, as applicable.
 
4.      IANA registrations
All pending IANA registrations related with 3GPP work are expected to progress as part of the work when the related drafts become RFCs.
 
It was not known at the time of meeting whether there is an open item in IANA registration of EAP-AKA attributes. Jari Arkko volunteered to check the status (AP 11).
 
5.      Emergency calls
Feedback mechanism via option tag has been discussed draft-patel-ecrit-sos-parameter to inform the UE whether the request was understood by the registrar or not. The latest version does not add the option tag, but adds an explanation of why emergency registration is needed is added and what happens if the registrar does not support the URI parameter in registration request. This draft has been agreed to progress as AD sponsored document (Cullen Jennings)
 
Callback has also been discussed recently in ECRIT and the work is progressing. Possible future work area may raise in non-voice emergency calls. The requirements need to be identified first and it was assumed (but not confirmed during the meeting) that NENA would be liaising to 3GPP on non-voice emergency calls.
 
Callback is removed from 3GPP Rel-9 requirements but this does not mean that 3GPP is abandoning that requirement. This decision should be considered as commitment to use IETF based approach for callback indication and giving more time to get it completed.
 
6.      Review of 3GPP – IETF dependency document
The following new Rel-8 dependencies have been identified since the previous update of the dependency document:
  • draft-ietf-sipcore-invfix
  • draft-ietf-sip-ipv6-abnf-fix
  • draft-ietf-mmusic-ice-tcp
  • draft-ietf-sipcore-keep
  • draft-ietf-mediactrl-vxml
  • draft-ietf-mediactrl-sip-control-framework
  • draft-ietf-mediactrl-ivr-control-package
  • draft-ietf-mediactrl-mixer-control-package
  • draft-kaplan-dispatch-session-id
 
draft-ietf-simple-xcap-diff: Waiting for AD go-ahead in Sep 2009 (Robert Sparks) New version published in Jan 2010. It is being evaluated whether WG still needs to re-review this draft.
 
draft-ietf-simple-common-policy-caps: The draft has expired, and is not going to proceed to RFC. CT1 needs to take out the reference from 24.141
 
draft-ietf-sip-xcapevent and draft-sipping-config-framework: CT1 have replaced their references to config-framework with refs to xcapevent. SA4 have also analysed their situation and intend to keep using config-framework in 3GPP TS 26.237.
 
draft-ietf-ipv6-abnf-fix will progress as AD sponsored draft (Robert Sparks).
 
draft-drage-sipping-rfc3455bis has expired but it will be needed by 3GPP. It has been agreed to discuss among the interested people in San Francisco during CT1 #63 meeting week how to progress this work. The draft should progress as AD sponsored draft and further discussions on IETF side should take place on SIPPING list.
 
draft-dime-qos-attributes is now an RFC.
 
draft-patel-dispatch-cpc-oli-parameter replaces draft-mahy-iptlel-cpc. This work is expected to spin of a new mini-WG under DISPATCH.
 
draft-drage-sipping-service-identification has been in IESG evaluation since September 2009 and revised draft is needed to handle the comments that have been made.
 
draft-ietf-mmusic-sdp-capability-negotiation has been in IESG evaluation since June 2009, revised ID is needed and we are waiting for new version. New version was submitted and it has been requested that this draft should go back to WG
 
draft-uy-tel-dai is indicated as dead in I-D tracker. There has been intention to submit a new version to DISPATCH, but that has not happened yet. New version of the draft would need to be submitted.
 
draft-netlmm-pmip6-ipv4-support is in IESG evaluation since Nov 2009 and has received comments in IPSec area. Substantial re-write of the draft to address the comments has received rough consensus. AD review of the new version is still required before asking for IESG approval
 
draft-ietf-mip4-rfc3344bis has been revised to new draft version in Jan 2010. It is waiting for shepherd writeup. There has been very little activity in TSG CT on 24.304 recently as the latest versions do not require changes in 3GPP TSs, so CT1 is waiting for the draft to be completed.
 
draft-johnston-sipping-cc-uui has been revised to draft-johnston-dispatch-cc-uui. CT1 needs to update 24.229. It has been agreed to charter a new mini-WG to handle this draft.
 
draft-jesske-sipping-etsi-ngn-reason is replaced with draft-jesske-dispatch-reason-in-responses. The editor has been requested to split out the protocol changes from the use cases more clearly
 
draft-das-mipshop-andsf-dhcp-options proceeds as an AD sponsored draft (Jari Arkko). MIPSHOP review was requested and that has now been passed. 3GPP needs to determine more precisely the use of the draft.
 
draft-vanelburg-sipping-private-network-indication has a new name under DISPATCH WG and CT1 needs to check whether they have updated their specifications already. The authors need to drive this work in DISPATCH group.
 
draft-ietf-bliss-call-completion needs the editor to respond to technical issues that have been raised before the draft is ready for WG LC.
 
Two drafts have been merged to draft-dawes-sipping-debug and CT1 have already updated their specifications on this. It was agreed that the work on this draft will need to continue in DISPATCH.
 
draft-bakker-sipping-3gpp-ims-xml-body-handling will progress as AD sponsored draft (Cullen Jennings).
 
draft-mmusic-ice-tcp is marked as dead in IETF I-D tracker, but a new version has been distributed. 3GPP has got a reference towards this draft and needs to know whether the document is expected to progress or not.
 
7.      Next meeting
Hannu cannot participate IETF #77 so the next meeting was agreed to be a telco on the last week of April 2010, with April 28 agreed as the tentative date.
 
8.      Any Other business
It was agreed to collect comments and revisions on these minutes until Friday the 19th of February 12:00 noon UTC so that Hannu can distribute the reviewed and agreed version on 3GPP TSG CT mailing list and IETF RAI, INT and OPS mailing lists during the same day.
 
Jari Arkko gave the following comment via email after the meeting, to cover his AP 11 from this meeting:
 
“IANA has an expert that reviews these requests (Vesa Lehtovirta). While he was also specifying some of this work on the 3GPP side, in the IANA review he did spot an issue in the way that the attribute bit fields are defined. The issue is being rectified in CT1, they will handle a CR next week to fix 24.302. Once this is approved, I think we are all set and the IANA allocation can be made.”
 
Cullen Jennings made the following comment related with AP 13 on draft-mmusic-ice-tcp from this meeting:
 
“This draft expired (no new version for 6 months) and for some reasons the idtracker moved it to dead when it expired. I'm not sure why this happened but I moved it back to AD-Watching. My understanding of the situation is that the ietf community believes ice-tcp is needed and would like it to move forward but it needs a lot of work and the no one seems willing to put the time in to finish it. So with no one really moving ice-tcp forward, there is not much happening on the SDP attributes for it. It is not making much forward progress right now.”
 
9.      Closing
The meeting was closed at 17:50 UTC.
 
 
 
BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724
 
 
_______________________________________________
Int-area mailing list
Int-area <at> ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Ralph Droms | 19 Feb 2010 19:35
Picon

DHCP-based subscriber authentication


In July, 2007, the DSL Forum (now the Broadband Forum, or BBF) sent a
liaison to the IETF [1] asking about solutions for the problem of
subscriber authentication in DSL networks, which included a list of
requirements for any solutions.  In October, 2007, the DSL Forum sent
a second liaison [2] asking more specifically that the IETF take on a
work item to develop a subscriber authentication mechanism based on
DHCP, as described in draft-pruss-dhcp-auth-dsl-01.txt or
draft-zhao-dhc-user-authentication-02.

There was a long discussion of DHCP-based subscriber authentication at
the IETF 70 intarea open session.  A poll to determine consensus about
taking on the work item was inconclusive.  The outcome of the
discussion was to ask the dhc WG to write an analysis of the mechanism
proposed in draft-pruss-dhcp-auth-dsl, as a way of providing better
information to the decision about whether or not to take on the work.

Writing the analysis turned out to be an interative process, in which
draft-pruss-dhcp-auth-dsl was updated to reflect the points made in
the analysis document, followed by updates to the analysis to reflect
the changes in draft-pruss-dhcp-auth-dsl.  That process has converged;
the analysis is available in draft-jjmb-dhc-eap-auth-analysis-02 and
the updated DHCP-based authentication specification is in
draft-pruss-dhcp-auth-dsl-07.

Now that the analysis is complete, the intarea can reconsider the
original question: should the IETF take on this work?  We will
allocate some time in the intarea open session at the upcoming IETF to
a discussion and resolution the question.  In preparation for that
discussion, please review the analysis and protocol documents, and
post comments to the int-area <at> ietf.org mailing list.

- Ralph and Jari

[1] https://datatracker.ietf.org/documents/LIAISON/file457.doc
[2] https://datatracker.ietf.org/documents/LIAISON/file490.doc
Templin, Fred L | 23 Feb 2010 20:04
Picon
Favicon

Re: confirming consensus form themeeting: draft-templin-intarea-seal

Hi Jari,

SEAL has now been published as an experimental RFC:

  http://www.rfc-editor.org/rfc/rfc5320.txt

There is also an RFC5230-compliant implementation available
which I would encourage folks to have a look at:

  http://osprey67.com/seal

There is also an ongoing (bis) effort underway to
develop a greatly improved version of SEAL:

  http://tools.ietf.org/html/draft-templin-intarea-seal

Since the Hiroshima meeting, there have been numerous
list discussions indicating very real path MTU issues
in the Internet today:

http://www.ietf.org/mail-archive/web/rrg/current/msg05831.html
http://www.ietf.org/mail-archive/web/rrg/current/msg05860.html
http://www.ietf.org/mail-archive/web/rrg/current/msg05907.html
http://www.ietf.org/mail-archive/web/softwires/current/msg01161.html
http://www.ietf.org/mail-archive/web/softwires/current/msg01186.html
http://www.ietf.org/mail-archive/web/behave/current/msg08093.html

Research efforts have also shown significant evidence of
the issues:

http://www.icir.org/tbit/tbit-Aug2004.pdf
http://www.caida.org/workshops/wide/0603/slides/mluckie2.pdf
http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/000708.html

These investigations seem to confirm that IPv4 path MTU
discovery in the Internet today seems to be getting by
based solely on the fact that it is only very rarely
invoked. Otherwise, we would be seeing non-negligible
instances of path MTU-related black holes during ordinary
http transactions. As more and more tunnels are introduced
into the Internet however, this delicate balance will be
upset and we will have a path MTU mess to deal with. This
will not be a problem for tunnels that use SEAL.

I know we talked about SEAL in Hiroshima, but given these
new developments perhaps we should talk about it again
in Anaheim?

Thanks - Fred
fred.l.templin <at> boeing.com

> -----Original Message-----
> From: int-area-bounces <at> ietf.org [mailto:int-area-bounces <at> ietf.org] On Behalf Of Jari Arkko
> Sent: Tuesday, December 29, 2009 2:44 PM
> To: Internet Area
> Subject: Re: [Int-area] confirming consensus form themeeting: draft-templin-intarea-seal
> 
> Consensus has been confirmed to be the same as in the meeting, i.e., we
> will not adopt this work at this time. Of course, Fred has an RFC out on
> this in a week or two from the Independent Submission stream and I
> encourage everyone who is interested on this to take a look and/or
> consider using SEAL.
> 
> Jari
> 
> _______________________________________________
> Int-area mailing list
> Int-area <at> ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

Gmane