headers
Soohong Daniel Park | 1 Oct 2004 02:08

RE: IPv6 tunnelling options for IPv4

> I've been reviewing draft-daniel-dhc-ipv6in4-opt-04.txt - does
> draft-daniel-dhc-ipv6in4-opt-04.txt specify "configured IPv6-over-IPv4
> tunneling", as described in section 4 of RFC 2893?  If so, it would be
> helpful to include a specific reference, as there are numerous 
> tunneling and
> "IPv6-xxx-IPv4" transition mechanisms...

So, I've added this concern into the revised version.

> 
> I can imagine the mechanism in 
> draft-daniel-dhc-ipv6in4-opt-04.txt as being
> useful in the following scenario:
> 
> <---IPv6---->|<-------------IPv4 only----------->|<--IPv6--...
> 
>           +-------+     +------+              +--------+
>           |  CPE  |     | Edge |      ISP     | Tunnel |
>           |gateway+-----+Router+-----core-----+endpoint|
>           +-------+     +------+       |      +--------+
>                                    +---+--+
>                                    | DHCP |
>                                    |server|
>                                    +------+
> 
> In this scenario, the CPE gateway uses DHCPv4 to obtain its IPv4 
> address and
> other configuration information.  The DHCPv4 configured tunnel endpoint
> option would provide the IPv4 address of the ISP tunnel endpoint 
> as part of
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bernie Volz | 1 Oct 2004 19:45
Picon
Favicon

RE: IPv6 tunnelling options for IPv4

Hi:

Because there are so many different tunnel technologies and so many
different ways in which these can be used, clarity would be extremely
useful. So, I'd highly recommend adding diagrams and descriptions of the
likely uses unless there are good IETF documents elsewhere that can be
referenced (and referenced explicitly, with figure and section numbers).

I don't understand the diagram you included Daniel. Modifying Ralph's,
perhaps it should look like:

          IPv6|<-------------IPv4 only----------->|<--IPv6--...

          +-------+            IPv4          +--------+
          | Dual  |          network         | Tunnel |
          | Host  +------------core----------+endpoint|
          +-------+              |           +--------+
                             +---+--+
                             | DHCP |
                             |server|
                             +------+

The Dual [Stack] host tunnels traffic over IPv4 to get IPv6 connectivity.

I'm also wondering whether there would ever need to be any redundancy in the
tunnel end-points and whether returning a list of IPv4 addresses would be
appropriate. The node can try the first, if no response (not exactly sure
how it would tell - no RA?), it can try the others? But perhaps this is
unneeded complexity at this time as there may not be any easy way for a node
to tell if the end-point is up?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Soohong Daniel Park | 2 Oct 2004 01:43

RE: IPv6 tunnelling options for IPv4

Hi Bernie

> Because there are so many different tunnel technologies and so many
> different ways in which these can be used, clarity would be extremely
> useful. So, I'd highly recommend adding diagrams and descriptions of the
> likely uses unless there are good IETF documents elsewhere that can be
> referenced (and referenced explicitly, with figure and section numbers).

no problem here.

> I don't understand the diagram you included Daniel. Modifying Ralph's,
> perhaps it should look like:
> 
>           IPv6|<-------------IPv4 only----------->|<--IPv6--...
> 
>           +-------+            IPv4          +--------+
>           | Dual  |          network         | Tunnel |
>           | Host  +------------core----------+endpoint|
>           +-------+              |           +--------+
>                              +---+--+
>                              | DHCP |
>                              |server|
>                              +------+
> 
> The Dual [Stack] host tunnels traffic over IPv4 to get IPv6 connectivity.

It's why we need a IPv6-over-IPv4 tunnel. There are several possible
use cases according to this tunnel and your depict is one of them.

> I'm also wondering whether there would ever need to be any
(Continue reading)

Permalink | Reply | 1 comment |
headers
OTA Masazumi | 4 Oct 2004 09:47
Picon

All_DHCP_SERVERS Multicast address

Hello,

Could you please answer my question about All_DHCP_SERVERS Multicast address?

Can I think that the All_DHCP_SERVERS multicast packet defined as Site
local Address exceeds router in the same site? 

On the other hand, it is a direction where the use of a site local
address with IPv6 is prohibited. How is the All_DHCP_SERVERS multicast
address used for the future? 

Masazumi
Permalink | Reply | 2 comments |
headers
Stig Venaas | 4 Oct 2004 12:30
Picon
Picon

Re: All_DHCP_SERVERS Multicast address

On Mon, Oct 04, 2004 at 04:47:44PM +0900, OTA Masazumi wrote:
> Hello,
> 
> Could you please answer my question about All_DHCP_SERVERS Multicast address?
> 
> Can I think that the All_DHCP_SERVERS multicast packet defined as Site
> local Address exceeds router in the same site? 

The site boundary should be defined on the border routers so that they
don't forward packets or send e.g. PIM messages for site-scoped groups
outside the site.

> On the other hand, it is a direction where the use of a site local
> address with IPv6 is prohibited. How is the All_DHCP_SERVERS multicast
> address used for the future? 

It's only the site local unicast addresses that are gone. Scoping for
IPv6 multicast has not changed in any way.

Stig
Permalink | Reply | 1 comment |
headers
OTA Masazumi/太田正純 | 4 Oct 2004 12:56
Picon

Re: All_DHCP_SERVERS Multicast address

Thank you for your reply.

I understood 
 Border router judge whether packets can pass or not.
 Site local multicast address is alive.

-Masazumi
Permalink | Reply | 0 comments |
headers
The IESG | 4 Oct 2004 21:09
Picon
Favicon

Last Call: 'Rapid Commit Option for DHCPv4' to Proposed Standard

The IESG has received a request from the Dynamic Host Configuration WG to 
consider the following document:

- 'Rapid Commit Option for DHCPv4 '
   <draft-ietf-dhc-rapid-commit-opt-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2004-10-18.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-05.txt

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 4 Oct 2004 21:44
Picon
Favicon

I-D ACTION:draft-ietf-dhc-server-override-01.txt

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

	Title		: DHCP Server-ID Override Suboption
	Author(s)	: R. Johnson, et al.
	Filename	: draft-ietf-dhc-server-override-01.txt
	Pages		: 5
	Date		: 2004-10-4
	
This memo defines a new suboption of the DHCP relay information
option [6] which allows the DHCP relay to specify a new value for the
Server-ID option, which is inserted by the DHCP Server.  In some
cases it is convenient for the DHCP relay to act as the actual DHCP
server such that DHCP RENEWAL requests will come to the relay instead
of going to the server directly.  This gives the relay the
opportunity to include the Relay Agent option with appropriate
suboptions even on RENEWAL messages.
This new relay agent suboption allows the relay to tell the DHCP
server what value to use in the Server-ID option [3].  If this
suboption is not present, the server should build the Server-ID
option in the normal fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-01.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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 4 Oct 2004 21:44
Picon
Favicon

I-D ACTION:draft-ietf-dhc-vpn-option-03.txt

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

	Title		: DHCP VPN Information option
	Author(s)	: R. Johnson, et al.
	Filename	: draft-ietf-dhc-vpn-option-03.txt
	Pages		: 6
	Date		: 2004-10-4
	
This memo defines a new DHCP option for passing VPN information
between the DHCP client and the DHCP server.  It is intended for use
primarily by DHCP proxy clients in situations where VPN information
needs to be passed to the DHCP server for proper address allocation
to take place.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-03.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 username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-vpn-option-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Soohong Daniel Park | 7 Oct 2004 01:30

IPv6-over-IPv4 Tunnel with DHCP (Ready for WG Item ?)

Hello Folks

The latest version of draft-daniel-dhc-ipv6in4-opt appears in the
IETF repository as below:  
http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-05.txt

Above all, this protocol works well in our enterprise networks.

Change log:

1. Added some text with use case and detailed flow of this protocol.
2. Text improvement around this draft.
3. Added Terminology section to clarify what tunnel is used in this draft.
4. Added Implementation Experience section for useful information.

Now, I'd ask the dhc folks whether it is ready to be accepted 
as official WG Item or not...

Let me know your view on this.

     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics.
Permalink | Reply | 0 comments |

Gmane