headers
Cullen Jennings | 6 Nov 2007 19:29
Picon
Favicon
Gravatar

Small comment on draft-ietf-v6ops-cpe-simple-security


I'm sure the idea of repeating recommendations in the "Summary of  
Recommendations" section will be sort of controversial at some point,  
however, I would really like to encourage you to add the summary as  
you have it in the draft now. I have had much better luck getting  
things like this adopted in products  from folks like Linksys and  
Netgear when I could hand a product manager a page of requirements  
that they could cut and paste into their product requirements  
specifications. If this is summary of recommendation contains all the  
normative language you need, I think it really helps make it easier  
to get the vendors to adopt this. Unlike much of the equipment that  
implements IETF protocols, the types of devices you are describing  
here are often contracted out using an ODM model and being able to  
express requirements like this makes it easier to include them.

I suspect we don't have a lot of product manager for the types of  
devices we are talking about participating in this WG but if this  
document makes their life easy, that would be good.

I'm not sure what to say about multicast but I'm sure that advice  
would be useful.

Cullen <with my individual hat on>
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 7 Nov 2007 18:40
Picon
Favicon

I-D Action:draft-ietf-v6ops-addcon-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : IPv6 Unicast Address Assignment Considerations
	Author(s)       : G. Van de Velde, et al.
	Filename        : draft-ietf-v6ops-addcon-07.txt
	Pages           : 33
	Date            : 2007-11-07

One fundamental aspect of any IP communications infrastructure is its
addressing plan.  With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network
designers and operators need to reconsider their existing approaches
to network addressing.  Lack of guidelines on handling this aspect of
network design could slow down the deployment and integration of
IPv6.  This document aims to provide the information and
recommendations relevant to planning the addressing aspects of IPv6
deployments.  The document also provides IPv6 addressing case studies
for both an enterprise and an ISP network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-07.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gunter Van de Velde (gvandeve | 7 Nov 2007 18:55
Picon
Favicon

RE: New Version Notification for draft-ietf-v6ops-addcon-07

 Hi All,

We found a technical typo wrt 'u and 'g' bits. This new daft corrects
this typo.

s/81/71/
s/82/72/

G/

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@...] 
Sent: Wednesday, November 07, 2007 6:37 PM
To: gunter (mailer list)
Cc: v6ops@...; Chip Popoviciu (cpopovic); tjc@...;
Olaf.Bonness@...; HahnC@...
Subject: New Version Notification for draft-ietf-v6ops-addcon-07 

A new version of I-D, draft-ietf-v6ops-addcon-07.txt has been
successfuly submitted by Gunter Van de Velde and posted to the IETF
repository.

Filename:	 draft-ietf-v6ops-addcon
Revision:	 07
Title:		 IPv6 Unicast Address Assignment Considerations
Creation_date:	 2007-11-05
WG ID:		 v6ops
Number_of_pages: 33

Abstract:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 8 Nov 2007 02:59
Picon

Re: Follow-up work on NAT-PT

On 2007-10-30 11:54, Brian Dickson wrote:
> Brian E Carpenter wrote:
>> The IAB request specifically asks for a solution for IPv6-only
>> hosts. It's long been my view that the primary coexistence strategy
>> must be dual-stack, but I'm trying to answer the IAB's question.
>>
>>>
>>> Finally, from my reading the usefulness of SHANTI is only where the 
>>> IPv6-only host has an application that appreciates IPv4 parameters 
>>> (port and address) or the translation itself. Do we expect 
>>> application developers to widely cater for this scenario, or to make 
>>> the assumption that "if IPv4 matters we should use the IPv4 stack"?
>>
>> No, SHANTI will work out of the box for any application that runs
>> through a traditional NAT or NAPT without problems *and* has been
>> upgraded to AF_INET6 sockets. However, applications that require
>> an ALG with traditional NA(P)T will need to be tweaked, I think.
>> The question is whether that overhead is justified to get rid of
>> the problems of NAT-PT?
>>
>>     Brian
> I've been giving thoughts to some of the issues along similar lines.
> 
> Here's what I've been thinking of, in terms of a solution space:
> 
> Protocol translation that uses IPv6 as a transport, but doesn't do 
> anything other than present IPv4 on an IPv6-only host.

I'm not sure how this is different from Bump in the Stack (RFC 2767)
or Bump in the API (RFC 3338), as you describe it above.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 8 Nov 2007 03:46
Picon

[Fwd: I-D Action:draft-carpenter-shanti-01.txt]

I've fixed a lot of errors and inconsistencies in this version.
I'd really like to know if the idea holds water. Active co-authors
would be most welcome. Critical review by someone who's been
tracking BEHAVE would be most welcome.

     Brian

-------- Original Message --------
Subject: I-D Action:draft-carpenter-shanti-01.txt
Date: Wed, 07 Nov 2007 21:30:02 -0500
From: Internet-Drafts@...
Reply-To: internet-drafts@...
To: i-d-announce@...

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Shimmed IPv4/IPv6 Address Network Translation Interface (SHANTI)
	Author(s)       : B. Carpenter
	Filename        : draft-carpenter-shanti-01.txt
	Pages           : 16
	Date            : 2007-11-07

There is a pragmatic need for a packet-level translation mechanism
between IPv4 and IPv6, for scenarios where no other mode of IPv4 to
IPv6 interworking is possible.  The mechanism defined here uses a
shim in both the translator and the IPv6 host to mitigate the
problems introduced by stateless translation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-shanti-01.txt
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 8 Nov 2007 22:07
Picon

Re: Follow-up work on NAT-PT - a new approach

On 2007-11-09 07:22, Rémi Després wrote:
> Brian Dickson wrote :
>> Brian E Carpenter wrote:
>>> The IAB request specifically asks for a solution for IPv6-only
>>> hosts...
>> ...
>>
>> On the IPv6-only host, add an IPv4 "thing". (interface/driver/whatever).
>>
> If IPv6 hosts could be kept simple (i.e. unmodified for IPv6 to IPv4 
> connectivity), that would be a better perspective for IPv6 deployment.

I don't see that. IPv6 stacks are still in flux and being actively
worked on. In any case, my analysis of RFC 4966 is that without
adding state in the IPv6 host, most of the problems identified
with NAT-PT cannot be mitigated. draft-carpenter-shanti-01
covers this in some detail.

      Brian

> 
> One approach for this would be that the DNS would automatically return 
> IPv4 mapped addresses to IPv6 queries when they have no IPv6 address but 
> have at least one IPv4 address.
> Then boxes on the client-to-server paths which car support NAT for IPv4 
> connections (typically customer edge routers) can do the protocol 
> conversion.
> 
> The conversion would be a particular (simplified) NAT-PT (no 
> fragmentation, and the same ALGs as deemed useful in IPv4 NATs ).
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Curran | 8 Nov 2007 23:03
Picon

Re: Follow-up work on NAT-PT - a new approach

At 10:07 AM +1300 11/9/07, Brian E Carpenter wrote:
> In any case, my analysis of RFC 4966 is that without
>adding state in the IPv6 host, most of the problems identified
>with NAT-PT cannot be mitigated. draft-carpenter-shanti-01
>covers this in some detail.

Brian -

  How does an ISP grow their network (using IPv6 to connect
  customers) without some way to provide the minimal level
  of backward compatibility to the existing IPv4-connected
  Internet which is provided by NAT-PT?

/John
Permalink | Reply | 4 comments |
headers
Brian E Carpenter | 8 Nov 2007 23:25
Picon

Re: Follow-up work on NAT-PT - a new approach

On 2007-11-09 11:03, John Curran wrote:
> At 10:07 AM +1300 11/9/07, Brian E Carpenter wrote:
>> In any case, my analysis of RFC 4966 is that without
>> adding state in the IPv6 host, most of the problems identified
>> with NAT-PT cannot be mitigated. draft-carpenter-shanti-01
>> covers this in some detail.
> 
> Brian -
>  
>   How does an ISP grow their network (using IPv6 to connect
>   customers) without some way to provide the minimal level
>   of backward compatibility to the existing IPv4-connected
>   Internet which is provided by NAT-PT?

I must confess that I've looked at the question much more from
the viewpoint of a campus or enterprise network, on the assumption
that ISPs only provide some combination of IPv4 and IPv6
transport. And there the answer for me has always been: upgrade
servers to dual stack, and install dual-stack application proxies
to fill any gaps.

I would envisage a similar approach for an ISP supporting
SOHO subscribers - that really isn't much different from
a campus network. The ISP will need dual-stack mail servers,
for example. Anyone providing services to the public will need
a dual stack, for that matter, if they want to be accessible.

However, for the residual cases, it's precisely because
of the issues with NAT-PT that I've just started working
on SHANTI. Whether that's of value is for the community
(Continue reading)

Permalink | Reply | 3 comments |
headers
Internet-Drafts | 9 Nov 2007 00:15
Picon
Favicon

I-D ACTION:draft-ietf-v6ops-addr-select-req-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Requirements for address selection mechanisms
	Author(s)	: A. Matsumoto, et al.
	Filename	: draft-ietf-v6ops-addr-select-req-04.txt
	Pages		: 9
	Date		: 2007-11-8
	
In a multi-prefix environment, nodes could have multiple addresses on
   one network interface.  RFC 3484 defines a source and destination
   address-selection algorithm, which is commonly deployed in current
   popular OSs.  However, nodes could encounter some difficulties in
   network communication when they use default address selection rules
   defined in RFC 3484.  Some mechanisms for solving address-selection
   problems are proposed including the RFC 3484 policy table
   distribution and ICMP error-based mechanisms.  This document
   describes requirements for these address-selection mechanisms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-req-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Curran | 9 Nov 2007 00:27
Picon

Re: Follow-up work on NAT-PT - a new approach

At 11:25 AM +1300 11/9/07, Brian E Carpenter wrote:
>I would envisage a similar approach for an ISP supporting
>SOHO subscribers - that really isn't much different from
>a campus network. The ISP will need dual-stack mail servers,
>for example. Anyone providing services to the public will need
>a dual stack, for that matter, if they want to be accessible.

At some point, ISP's will: 1) Be unable to readily obtain additional
IPv4 address space, 2) Want to keep growing, and 3) Want a
method for connecting up customers via IPv6-only which provides
some semblance of full Internet connectivity (including backward
reachability to IPv4 destinations).

From the ISP point of view, some of the key requirements are:

 - Has to require a minimal amount of special per-site
   (or per-site-host) configuration in order to provide
   the connectivity to Internet IPv4-only sites.

 - Allow for sharing of some IPv4 space that the ISP
   has set aside for such purposes.

 - Allow implementation of the same "site" policies
   (such as port-based firewall filters) on the IPv4
   backward-compatible connectivity that customers
   use today to provide nominal security.

Contrary to what a lot of folks think, I don't think that the
backwards-compatibility IPv4 connectivity really needs to
be general purpose, or application friendly, or support a
(Continue reading)

Permalink | Reply | 2 comments |

Gmane